Conan: Warning in CMake file created by conan

[mcraveiro]

Hi guys,

This is not causing me any problems as such, but I thought I'd let you guys know. Noticed this on my build[1]:

CMake Warning (dev) in build/output/conanbuildinfo.cmake:
  Syntax Warning in cmake code at
    /home/travis/build/DomainDrivenConsulting/dogen/build/output/conanbuildinfo.cmake:142:88
  Argument not separated from preceding token by whitespace.
Call Stack (most recent call first):
  CMakeLists.txt:30 (include)
This warning is for project developers.  Use -Wno-dev to suppress it.

Presumably conanbuildinfo.cmake is generated by Conan. Worth clearing up that warning...

Cheers

[1] https://travis-ci.org/DomainDrivenConsulting/dogen/jobs/107194308

[memsharded]

I dont have acces to the travis build dir, and I have not been able to reproduce the issue in any of my projects. Would you mind to check the offending line (142) in your conanbuildinfo.cmake and copy it here? So I can try to figure out the problem. Thanks!

[mcraveiro]

Hi,

I did a quick hack on my travis file and got this output. It basically has lines 135 onwards up to 145.

$ sed -n '135,145p' /home/travis/build/DomainDrivenConsulting/dogen/build/output/conanbuildinfo.cmake
    #write output values
    list(GET VERSION_LIST 0 ${MAJOR})
    list(GET VERSION_LIST 1 ${MINOR})
endmacro()
macro(ERROR_COMPILER_VERSION)
    message(FATAL_ERROR "Incorrect '${CONAN_COMPILER}' version 'compiler.version=${CONAN_COMPILER_VERSION}'"
                        " is not the one detected by CMake: '${CMAKE_CXX_COMPILER_ID}="${VERSION_MAJOR}.${VERSION_MINOR}')
endmacro()
macro(CHECK_COMPILER_VERSION)
The command "sed -n '135,145p' /home/travis/build/DomainDrivenConsulting/dogen/build/output/conanbuildinfo.cmake" exited with 0.

Cheers

[memsharded]

Thanks, it is the missing space, yes, now I see it. Fixed in commit together with other fixes to conanbuildinfo.cmake, might release a minor 0.7.1 with it.

[mcraveiro]

Thanks a lot! Let me know when you spin it and I'll confirm the fix.

Cheers

Marco

[memsharded]

Hi Marco,
We have released 0.7.1 that should fix this problem, if you want to confirm the fix.
Best

[mcraveiro]

Hi,

Thanks for that. I did a build; not quite sure whats going on but I'm now red and I changed nothing in the code :-) thing is, it's not obvious it's a conan problem either:

https://travis-ci.org/DomainDrivenConsulting/dogen/jobs/107891360

Seems like travis can't find my targets any more. The only strange conan related bit is:

-- Setting up Conan support.
-- WARN: CONAN_COMPILER variable not set, please make sure yourself that your compiler and version matches your declared settings
-- Configuring done
-- Generating done

Could this be causing the problem? Seems like it isn't as I had a similar warning before:

https://travis-ci.org/DomainDrivenConsulting/dogen/jobs/107449745

The other interesting thing is that it seems CMake stops straight after (or during) conan processing, if I compare the logs.

Cheers

[memsharded]

Hi Marco,

No, this is a regular "STATUS" message from cmake, so it shouldn't be the origin of your problem. Yes, we added this warning in 0.7.1, as the compiler checks that are implemented in conanbuildinfo.cmake can only be done when using the conan build command, and if invoking cmake directly, it is the responsibility of the user to match the build with the install settings used for conan. It already was, it is just a message to be careful. Is it possible that any of your process might be capturing the "WARN" text from the output and stopping it? Doesn't seem reasonable, but I don't have any other idea right now.

You can check what has changed in 0.7.1: https://github.com/conan-io/conan/commit/89655acaf32536fdd24de2c7cff4c46fcc71b629 Just info messages, no more, nothing should be broken.

Did you tried with 0.7? or the last successful build was with 0.6? Can you try to rebuild with 0.6 (installing with pip install conan==0.6 should make it)?

[mcraveiro]

It was building successfully with 0.7 as I started using the new feature for renaming the conan file. I will retrigger this build in case its just travis going a bit mad - but it did happen on both clang and gcc, so doesn't seem like a coincidence. Puzzling!

[mcraveiro]

Ok, I've got no idea whats going on - the function conan_check_compiler() looks pretty sound to me - but if I comment it out in the generated conanbuildinfo.cmake:

macro(CONAN_BASIC_SETUP)
  message(STATUS "here10")
  # conan_check_compiler()
  message(STATUS "here7")
...

It all works perfectly well; if I leave it there I never get to here7 and its like CMake just decides to end there. I have _absolutely_ no idea why :-D

[memsharded]

as a workaround for these problems, we added the CONAN_DISABLE_CHECK_COMPILER cmake variable. Maybe you prefer to add it to command line -DCONAN_DISABLE_CHECK_COMPILER=On, to disable compiler checks, instead of having to modify the conanbuildinfo.cmake, while we investigate what is happening here, thanks for your patience and support!

[mcraveiro]

No worries - I'll leave the build red for now and test it when you come up with a fix. No problems and good luck.

[memsharded]

0.7.3 released, should fix it, please tell us :)

[mcraveiro]

Cool, will give it a spin! :-) rebuilding! [1]

[1] https://travis-ci.org/DomainDrivenConsulting/dogen/jobs/108159382

[mcraveiro]

Still failing I'm afraid, but now for different reasons:

-- Setting up Conan support.
CMake Error at build/output/conanbuildinfo.cmake:141 (message):
  Incorrect 'gcc' version 'compiler.version=4.6' is not the one detected by
  CMake: 'GNU=5.2'
Call Stack (most recent call first):
  build/output/conanbuildinfo.cmake:182 (conan_error_compiler_version)
  build/output/conanbuildinfo.cmake:217 (check_compiler_version)
  build/output/conanbuildinfo.cmake:80 (conan_check_compiler)
  CMakeLists.txt:31 (CONAN_BASIC_SETUP)
-- Configuring incomplete, errors occurred!
See also "/home/travis/build/DomainDrivenConsulting/dogen/build/output/CMakeFiles/CMakeOutput.log".

[memsharded]

Hi Marco,

Maybe this is a valid output, and the reason why those checks were initially deployed.
The checks are complaining that you have declared to use gcc 4,6 in conan, but the actual compiler that CMake is using is gcc 5.2. These mistmatches might not be a problem if they are double cancelled, i.e., if the same mistake is done in the consumer of the package, which might be occuring in your case. But as long as someone or yourself try to consume a package that has been declared to build with 4.6, but actually was built with 5.2 (e.g. you are in a different machine which actually has 4.6), then ABI incompatibilities will start to produce weird link errors.

Could you please check if such mistmatch could be happening in your project? Please tell me, it could be that, or possibly is another bug, again, arghhhh XDDDD. Thanks!

[lasote]

Hi Marco!

I think I get it. Conan CMake compiler checker is now working fine. I think in previous conan's versions the checker was failing.

But now the problem is that conan auto detects gcc 4.6 but you have installed 5.2 and setted CC and CXX variables to use "gcc-5" executable. Conan currently uses always "gcc" command to detect the version, but in your case the right compiler executable is obviously "gcc-5".

So... we need to release another minor :sob: , the good new is that now we are detecting an error that we didn't catch in previous versions. :grinning:

Thanks Marco!!

[lasote]

0.7.4 is ready! relaunch your build please, we are crossing fingers! :smile:

[mcraveiro]

:-D pressed fire, will report back! [1]

[1] https://travis-ci.org/DomainDrivenConsulting/dogen/jobs/108159382

[mcraveiro]

Ok, good news bad news scenario! :-D good news is it's now gone past the previous errors and I think you guys solved the problem at hand. Bad news is the build is still red, but now I think it's related to the boost patches I'm carrying. Investigating.

[mcraveiro]

Actually, to be honest I'm not sure whats going on at all :-( I got a whole load of strange linking errors such as:

/home/travis/.conan/data/Boost/1.60.0/lasote/stable/package/ebdc9c0c0164b54c29125127c75297f6607946c5/lib/libboost_log.so: undefined reference to `std::invalid_argument::invalid_argument(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)@GLIBCXX_3.4.21'
/home/travis/.conan/data/Boost/1.60.0/lasote/stable/package/ebdc9c0c0164b54c29125127c75297f6607946c5/lib/libboost_log.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::find(char const*, unsigned long, unsigned long) const@GLIBCXX_3.4.21'
/home/travis/.conan/data/Boost/1.60.0/lasote/stable/package/ebdc9c0c0164b54c29125127c75297f6607946c5/lib/libboost_log.so: undefined reference to `std::runtime_error::runtime_error(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)@GLIBCXX_3.4.21'
/home/travis/.conan/data/Boost/1.60.0/lasote/stable/package/ebdc9c0c0164b54c29125127c75297f6607946c5/lib/libboost_filesystem.so: undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::rfind(char, unsigned long) const@GLIBCXX_3.4.21'

It almost seems like the version of boost supplied by conan is no longer working for me, but can't imagine why that would be...

[memsharded]

I am having a look. These errors are because of differences in the compiler version and lib, which now that it seems that it is detected ok, seems weird. Maybe the issue is in the Boost packages, they were generated in travis too by @lasote, so if the compiler detection failed in the past, it is possible that they don't match their declared compiler version either.

That would explain why it did work in the past, both packages (dogen and boost) could be doing same mistake, so they remain compatible. But not sure, I keep investigating.

[mcraveiro]

Ah yes, that would make perfect sense! Cheers

[memsharded]

I am also a bit surprised, in the OSX build: https://travis-ci.org/DomainDrivenConsulting/dogen/jobs/108159383

Auto detecting your dev setup to initialize conan.conf
Found gcc 4.2
Found clang 3.4
CC and CXX: clang-3.7, clang++-3.7 
Default conan.conf settings
    os=Linux
    arch=x86_64
    compiler=gcc
    compiler.version=4.2
    build_type=Release

ERROR: '4.2' is not a valid 'settings.compiler.version' value.
Possible values are ['4.4', '4.5', '4.6', '4.7', '4.8', '4.9', '5.1', '5.2', '5.3']

Are the travis machines actually providing a gcc 4.2?? In any case, as ENV variables are defined for clang, maybe the default settings should be taken from clang, instead of gcc.

[memsharded]

I have been able to locally build dogen, with gcc 4.9, everything perfect. Conf below.
Maybe we are hitting the problem of two ABIs for gcc5? https://github.com/conan-io/conan/issues/129
I am installing gcc 5.2, to try locally too.

[full_settings]
    arch=x86_64
    build_type=Release
    compiler=gcc
    compiler.version=4.9
    os=Linux

[full_requires]
    Boost/1.60.0@lasote/stable:61e9701d8417a95a3264062633f910fdd015d633
    bzip2/1.0.6@lasote/stable:9cf83afd07b678d38a9c1645f605875400847ff3
    libiconv/1.14@lasote/stable:c6d75a933080ca17eb7f076813e7fb21aaa740f2
    libxml2/2.9.3@lasote/stable:e7747e606d14192bfa5da85eaeb9d13c988783ac
    zlib/1.2.8@lasote/stable:9cf83afd07b678d38a9c1645f605875400847ff3

[full_options]
    Boost:shared=True
    bzip2:shared=True
    libiconv:shared=False
    libxml2:shared=True
    zlib:shared=True

[memsharded]

With gcc 5.3, initially I had similar errors, then I issued a:

$ conan install ../.. -f=.conanfile.txt --build

with the --build flag to ensure that the dependencies are also built from source. And everything works fine. I have tried to look for something wrong in the Boost binary package, but without success. WIll ask tomorrow to @lasote.

[lasote]

@memsharded I'm looking at it. I bet the problem is related with the installed glibc version in travis machine (I suspect that may be an older glibc in travis that I used in a pure ubuntu installation with docker and gcc 5.2)

About the clang, it's not a osx build, both are linux, and conan priorize the gcc detection in linux. The only way to use clang would be manually specify the -s compiler=clang -s compiler.version=3.4

i'm preparing a repo to play with travis and get the glibc version used etc.

[lasote]

I was thinking about the clang detection and should be an additional problem in conan because it sets CC and CXX too. Conan should take clang before gcc... I will open an issue.

I keep investigating the linker problems, that are the really problem here ;)

[memsharded]

The locally generated boost (the one that do not produce linking errors) has the following objdump:

libgcc_s.so.1:
   0x0b792650 0x00 08 GCC_3.0
 se requere desde libpthread.so.0:
   0x09691a75 0x00 05 GLIBC_2.2.5
libstdc++.so.6:
   0x056bafd3 0x00 06 CXXABI_1.3
   0x0297f870 0x00 04 GLIBCXX_3.4.20
   0x08922974 0x00 03 GLIBCXX_3.4
libc.so.6:
   0x06969194 0x00 09 GLIBC_2.14
   0x0d696914 0x00 07 GLIBC_2.4
   0x09691a75 0x00 02 GLIBC_2.2.5

while the uploaded boost binary has:

libgcc_s.so.1:
   0x0b792650 0x00 09 GCC_3.0
 se requere desde libpthread.so.0:
   0x09691a75 0x00 06 GLIBC_2.2.5
libstdc++.so.6:
   0x056bafd3 0x00 07 CXXABI_1.3
   0x0297f870 0x00 05 GLIBCXX_3.4.20
   0x0297f871 0x00 04 GLIBCXX_3.4.21
   0x08922974 0x00 03 GLIBCXX_3.4
libc.so.6:
   0x06969194 0x00 10 GLIBC_2.14
   0x0d696914 0x00 08 GLIBC_2.4
   0x09691a75 0x00 02 GLIBC_2.2.5

The mismatch is precisely the GLIBCXX_3.4.21 that is causing the errors. Still don't know why the boost package generated in travis makes boost to use GLIBCXX_3.4.21 symbols, apparently the libstdc++.so is the same version, though the time stamp is different:

GLIBCXX: 20151031 (travis)
GLIBCXX: 20151010 (docker)

I'll keep investigating this issue tonight

[lasote]

I was reading some time about GLIBCXX issues and my theory is that in version 20151031 (20 days newer than mine) the symbols failing in your build, like *_"std::__cxx11::basic_stringbuf, std::allocator >::str() " *_ have changed (some change in the definition).

So when you compile Boost with last version (from travis) compiler doesn't found this symbol in glibcxx 3.4.21 and uses 3.4.20 (I read that its very common to mix glibcxx versions in a single libray).

It won't be a problem except by the fact that I compiled Boost against a glibcxx that have exactly those symbols in gcc 3.4.21 (but now they are missing).

It's just a theory, and it's a big mess, just a minor of glibcxx having the same compiler version could break the compatibility??? really???

I'm trying to find the changelog or the code of those libstdc++ versions and confirm the problem.

But if it was confirmed... what could we do? people with ubuntu billy and latest compiler will use the problematic glibc++ symbols so will break the compatibility with people installing gcc-5 from scratch. :cry:

[lasote]

Hi Marco! I've uploaded new Boost packages for gcc 5.2 and we want to see if now the symbols are found right. Could you relaunch it?
Thanks!

[mcraveiro]

yep, lemme give it a spin!

[mcraveiro]

No luck I'm afraid, same kind of linking errors:

https://travis-ci.org/DomainDrivenConsulting/dogen/jobs/108670231

May be worth checking it pulled the expected boost version, I guess.

[lasote]

Sorry for the delay, You are right, I checked the downloaded package and it's not correct. I will generate them again and I'll write you.

[lasote]

I've uploaded again the package and checked that it's compiled with the same compiler version that you have in travisci. Could you relaunch it? Thanks so much Marco.

[memsharded]

I have the same issue, with the recently created packages for ZMQ, created with conan-package-tools in travis with docker, and gcc-5.3.

--build works ok, building in my machine.

gcc-4.9 packages (docker-travis) work fine. It is something related to gcc>5.

I keep investigating

[memsharded]

Finally, I figured out! :)

The problem is as follows:

• Boost packages, generated with travis use docker to manage different versions of gcc, as gcc 5.2 or gcc 5.3
• Those docker images are using modern linux distros, e.g. > Ubuntu 15.10
• By default, new modern linux distros have switched to the gcc>5.1 new C++11 ABI, that is libstdc++ is built with gcc>5.1, usually named libcxx11, as well as the rest of the system. The libcxx11 ABI is incompatible with the old gcc<5.1 libcxx98 ABI.
• Building in such environment links with the new libcxx11 by default.
• Now, we move to our user, package consumer environment, which could be an Ubuntu 14.04, or a travis VM (12.04). Those distros use a libcxx98 libstdc++, as a lot of programs of those distros depends on the old libcxx98 ABI. It is not simple to replace it for the new one, requiring to rebuild or reinstall large part of the system and applications. Maybe it could be installed for dev only, and specified in the build, but I have not been able yet.

So the solution could be, when building with gcc>5.1, there are 2 options, as pointed out by @TyRoXx in https://github.com/conan-io/conan/issues/129. You can build packages to be consumed by users with libcxx98 and other packages with different ABI for users with libcxx11.

That, could integrate together with https://github.com/conan-io/conan/issues/124.

So, basically, we would need to add extra settings to manage these cases, something like:

libc: libcxx11, libcxx98, libc++

I know this might be a different view from @weatherhead99, and the question about where should conan stop managing about the build. But the truth is that binary packages are quite different, depending on the user setup. You can be using gcc5.3 in an ubuntu 14, then libcxx98, or maybe you are running gcc5.3 in ubuntu 15.10 with libcxx11, then requiring a different binary. It is not something optional (options are freely defined, not fixed by conan, and they could provide defaults per-package), it is a development setting. It cannot have a default (defined in the package), it is defined by our dev environment. So I'd say it is clearly a setting. The good news is that it is quite a system-wide setting, it just have to be defined by default in your _conan.conf_ file. And you will always be able to change it for a particular build, if you manage to have 2 different versions of libstdc++ in your system

$ //change somewhat your system libstdc++
$ conan install -s compiler=gcc -s compiler.libc=libcxx11

Internally, the information will be handled to generators, e.g. cmake one could do something like:

if(DEFINED CONAN_LIBC AND CONAN_LIBC STREQUAL "libcxx98")
    add_definitions (-D_GLIBCXX_USE_CXX11_ABI=0)
endif()

Please, I'd love to hear from you, give feedback, so we can start to work on this asap, as it can be a stopper for gcc>5.1 users in some distros. Thanks!

[TyRoXx]

The GCC ABI problem is similar to compiler.runtime (MD, MT) for Visual C++. This compiler has had two incompatible ABIs to the standard library since forever and Conan can already deal with that.

[memsharded]

Yes, agree, it is exactly the same problem as MSVC runtime linking. So if you don't disagree with that approach, then it just a matter to define the syntax to add in gcc and clang compilers. Would you like the proposed libc: libcxx11, libcxx98, libc++?, or maybe also runtime? Any other idea? It is important that other possible options (is there a c++11 incompatible libc++ library too?) are also considered. Thanks!

[Manu343726]

Do you have an option to set the stdlib yet? One approach is to use that option like stdlib: stdlibc++ (That is, g++ ... -stdlib=${compiler.stdlib}), and if you need extra ABI options append them so the stdlib option becomes a tuple: stdlib: stdlibc++, abi11 or something similar.

For example, consider:

$ conan install -s compiler=clang -s compiler.stdlib=stdlibc++,cxx11abi

Becomes:

if(DEFINED CONAN_STDLIB)
    SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -stdlib=${CONAN_STDLIB}")
    if((CMAKE_CXX_COMPILER MATCHES "clang" OR
        CMAKE_CXX_COMPILER MATCHES "gnu") AND
        CONAN_STDLIB_ABI STREQUAL "cxx11abi")
        add_definitions (-D_GLIBCXX_USE_CXX11_ABI=1)
    endif()
endif()

[memsharded]

The thing is that it has to be defined in settings.yml too, and it seems logical to be nested in compiler:

 gcc:
        version: ["4.4", "4.5", "4.6", "4.7", "4.8", "4.9", "5.1", "5.2", "5.3"]
        stdlib: [(stdlibc++, cxx11abi), (stdlibc++, cxx98abi), (libc++, cxx98abi)]

So finally, if the tuples values always come together, I'd say it is clear and simpler to write something like:

 gcc:
        version: ["4.4", "4.5", "4.6", "4.7", "4.8", "4.9", "5.1", "5.2", "5.3"]
        stdlib: [libstdc++11, libstdc++98, libc++]

And then:

$ conan install -s compiler=gcc -s compiler.stdlib=libstdc++11

seems simpler too. Then, the cmake code becomes slightly longer, but I'd say that if we have to choose, it should be simpler for the user command line, as long as the cmake code is typically not shown. What do you think? Thanks

[memsharded]

@Manu343726, I would like to support pure C builds (many base libs are just C), which name should I give to the option? "None"? "libgcc"? "libc"?

Also, what would be a system default? I mean, the one that conan auto-detects the first time. I think that libstdc++ should be harmless even if linking raw C with gcc instead of g++.

[Manu343726]

These are not the same thing:

• glibc and libgcc are the C runtime and gcc libs. These are part of the toolchain and tied to it. If you want to change these, you have to regenerate/change your gcc,ld,etc toolchain.
• -stdlib= g++/clang++ switch sets the C++ Standard Library implementation, which can be set at compile time using that switch.

If I got this issue correctly, the problem is with the C++ standard library ABI changes, so you don't have to worry about this in C builds.

So what I would do is to add a compiler.stdlib option for C++ packages to deal with STL implementation versioning.

[weatherhead99]

Not much to add, other than to say that there's a similar applicability to GCC on windows (cygwin) this problem has an analogue in the availability of DW2/SJLJ/SEH exception implementations. This is likely an exceptionally rare case though

[mcraveiro]

Hi guys,

sorry have been away for a few days. Apologies, after reading the posts I'm not too sure what's the latest - should rebuild just work now or do I need to update my files?

Cheers

marco

[memsharded]

Hi Marco,

No problem! Better wait until we release 0.8, that will include all the fixes around this libstdc++ dark gcc issues. Your project definitely helped to spot these problematic ABI compatibility issues. We hope the release will be this week, and will comment about how to proceed/update. In the meantime, I hope using --build could work for you. Thanks again for your patience!

[mcraveiro]

Ah cool! well, I'll wait for 0.8 then! No problems and keep up the good work! :-)

[lasote]

0.8 is here! :dancer:

[mcraveiro]

guys,

Sorry for the delays and thanks for the hard work on 0.8.0! I have ran a couple of builds with it, but I am getting stuck with a problem installing boost:

Boost/1.60.0@lasote/stable: Looking for package 7a415ecb019e0e4d63cb729d65a5e3c7d8aa56f2 in remote 'conan.io' 
Boost/1.60.0@lasote/stable: WARN: Binary for 7a415ecb019e0e4d63cb729d65a5e3c7d8aa56f2 not in remote: Package not found!
ERROR: Can't find a 'Boost/1.60.0@lasote/stable' package for the specified options and settings
- Try to build from sources with "--build Boost" parameter
- If it fails, you could try to contact the package author  at 'https://github.com/lasote/conan-boost', report your configuration and try to collaborate to support it.
Package configuration:
- Settings: arch=x86_64, build_type=Release, compiler=gcc, compiler.libcxx=libstdc++, compiler.version=5.2, os=Linux
- Options: shared=True, bzip2:shared=True, zlib:shared=True

Any ideas?

Cheers

[lasote]

It seems some packages are missing. Let me check what happened with them and upload them.

Thanks

[lasote]

I've uploaded the missing package for your configuration manually and launched CI systems to regenerate the rest of packages (in the next few hours). I did something wrong with the upload, sorry, some packages are missing. Try again please!

[mcraveiro]

Ok right, so I've got quite a bit further but its still a bit puzzling :-) I got a clang[1] and a gcc[2] build. The clang build failed as follows:

bzip2/1.0.6@lasote/stable: Installing package 096c80047f52a9d9b8a73d0943e67e11c0cbb7c0
bzip2/1.0.6@lasote/stable: Looking for package 096c80047f52a9d9b8a73d0943e67e11c0cbb7c0 in remote 'conan.io' 
bzip2/1.0.6@lasote/stable: WARN: Binary for 096c80047f52a9d9b8a73d0943e67e11c0cbb7c0 not in remote: Package not found!
ERROR: Can't find a 'bzip2/1.0.6@lasote/stable' package for the specified options and settings
- Try to build from sources with "--build bzip2" parameter
- If it fails, you could try to contact the package author  at 'http://github.com/lasote/conan-bzip2', report your configuration and try to collaborate to support it.

However this seems fine in the gcc build:

    Boost/1.60.0@lasote/stable:7a415ecb019e0e4d63cb729d65a5e3c7d8aa56f2
    bzip2/1.0.6@lasote/stable:50391cb89a05721e6453f19b4291fdf69aef2cf3
    libiconv/1.14@lasote/stable:0692fb2bd888ba708ca65670557c56d2e16851ed
    libxml2/2.9.3@lasote/stable:93b5193e58107fc7c1c92f29f37899dbffbe02b1
    zlib/1.2.8@lasote/stable:50391cb89a05721e6453f19b4291fdf69aef2cf3
bzip2/1.0.6@lasote/stable: Installing package 50391cb89a05721e6453f19b4291fdf69aef2cf3
bzip2/1.0.6@lasote/stable: Looking for package 50391cb89a05721e6453f19b4291fdf69aef2cf3 in remote 'conan.io' 
Downloading conan_package.tgz
[==================================================]                  
Downloading conanmanifest.txt
[==================================================]                  
Downloading conaninfo.txt
[==================================================]                  
bzip2/1.0.6@lasote/stable: Package installed 50391cb89a05721e6453f19b4291fdf69aef2cf3

Was this some kind of unlucky timing issue as packages were being uploaded? I also noticed the hashes are different for clang and gcc...

[1] https://travis-ci.org/DomainDrivenConsulting/dogen/jobs/116816304
[2] https://travis-ci.org/DomainDrivenConsulting/dogen/jobs/116816303

[lasote]

Hi Marco,

The hashes has to be different because there are not compatible between gcc and clang.
I usually just generate packages for gcc in linux, apple-clang in osx and visual studio in windows.
So it's normal that it doesn't find a package for clang in conan.io.

If you want to use it with clang you can use the --build missing option in conan install, but it will build ALL the missing packages, so the build will be long (and maybe it fails if some build tool is missing).
If you really need the packages for linux/clang open an issue in the package repository (lasote/conan-boost) and I will try to add them to the build matrix in travis.

Thanks Marco

[mcraveiro]

Ah I see - its just that I didn't see this problem before, so I was wondering if it was related to the other changes. Not to worry, I'll raise the ticket.
Cheers

[mcraveiro]

Ok cool I managed to get a green GCC build! [1] So as far as I am concerned the problem is solved. Thanks

[1] https://travis-ci.org/DomainDrivenConsulting/dogen/jobs/117064041

[lasote]

Great! This issue help us a lot! Thanks

[mcraveiro]

Hi Guys,

sorry to be a pain, but it seems this problem has re-emerged somehow :-( not sure what I am doing wrong. Basically at some point I started to get linking errors. Some of the flavour of the errors:

CMakeFiles/config_spec.dir/serialization_spec.cpp.o: In function `boost::archive::detail::common_oarchive<boost::archive::text_oarchive>::vsave(boost::archive::class_name_type const&)':
serialization_spec.cpp:(.text._ZN5boost7archive6detail15common_oarchiveINS0_13text_oarchiveEE5vsaveERKNS0_15class_name_typeE[_ZN5boost7archive6detail15common_oarchiveINS0_13text_oarchiveEE5vsaveERKNS0_15class_name_typeE]+0x47): undefined reference to `boost::archive::text_oarchive_impl<boost::archive::text_oarchive>::save(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)'
...
life_cycle_manager.cpp:(.text._ZN5boost3log12v2s_mt_posix15type_dispatcher13callback_base10trampolineINS1_9binder1stINS1_10output_funERNS1_11expressions3aux10stream_refINS1_24basic_formatting_ostreamIcSt11char_traitsIcESaIcEEEEEEENSt7__cxx1112basic_stringIwSB_IwESaIwEEEEEvPvRKT0_[_ZN5boost3log12v2s_mt_posix15type_dispatcher13callback_base10trampolineINS1_9binder1stINS1_10output_funERNS1_11expressions3aux10stream_refINS1_24basic_formatting_ostreamIcSt11char_traitsIcESaIcEEEEEEENSt7__cxx1112basic_stringIwSB_IwESaIwEEEEEvPvRKT0_]+0x5a): undefined reference to `boost::log::v2s_mt_posix::aux::code_convert_impl(wchar_t const*, unsigned long, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, std::locale const&)'

I am using GCC 5.3 which is the same as the GCC @lasote used to build the boost package (according to the manifest). Could this be a problem of C++11 vs C++ 98? The funny thing is that I get a different error in travis [1], and this is what I set out to replicate originally!

 17%] Linking CXX executable ../../../stage/bin/dogen.utility.spec
/home/travis/.conan/data/Boost/1.60.0/lasote/stable/package/cf85d4b84c387675a5c97eafca404d5b882d2f74/lib/libboost_thread.a(thread.o): In function `boost::this_thread::no_interruption_point::hiden::sleep_until(timespec const&)':
thread.cpp:(.text+0x465): undefined reference to `clock_gettime'
thread.cpp:(.text+0x4e7): undefined reference to `clock_gettime'
/home/travis/.conan/data/Boost/1.60.0/lasote/stable/package/cf85d4b84c387675a5c97eafca404d5b882d2f74/lib/libboost_thread.a(thread.o): In function `boost::this_thread::hiden::sleep_for(timespec const&)':
thread.cpp:(.text+0x27f3): undefined reference to `clock_gettime'
collect2: error: ld returned 1 exit status
make[3]: *** [stage/bin/dogen.utility.spec] Error 1
make[2]: *** [projects/utility/spec/CMakeFiles/utility_spec.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....

I can open up a new ticket, but I strongly suspect the root cause is something already described in this ticket - just not sure what :-D

[1] https://travis-ci.org/DomainDrivenConsulting/dogen/builds/131557381

[memsharded]

No worries, not a pain, we really need feedback like yours. We'll have a look asap.

[memsharded]

It seems that the build in travis is failing due to missing rt (-lrt). I have seen that you have added it here https://github.com/DomainDrivenConsulting/dogen/commit/03e25e2f3d704b8ae13b21990cce25b305ca8b01, so I am not sure why it is not working, probably you want to make sure that "rt" is actually being detected and used.

I have tried in my computer, but I am running linux on a VM, and it takes forever to build. So far it has passed the linking error without problems (I am Ubuntu 14.05, gcc 5.3). I have just forked dogen, and tomorrow will setup travis so I can run my own builds there and check for errors.

[mcraveiro]

That's most interesting @memsharded - I did try to get rid of those missing -lrt's quite a few times. In terms of replicating the problem locally, the plot thickens. So, if I take one of the missing symbols, say:

life_cycle_manager.cpp:(.text._ZN5boost3log12v2s_mt_posix3aux19date_time_formatterINS2_23decomposed_time_wrapperINS_10posix_time5ptimeEEEcE25format_fractional_secondsERNS8_7contextE[_ZN5boost3log12v2s_mt_posix3aux19date_time_formatterINS2_23decomposed_time_wrapperINS_10posix_time5ptimeEEEcE25format_fractional_secondsERNS8_7contextE]+0x16): undefined reference to `void boost::log::v2s_mt_posix::aux::put_integer<char>(std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >&, unsigned int, unsigned int, char)'

I then did:

[marco@lorenz lib]$ cd ~/.conan/data/Boost/1.60.0/lasote/stable/package/0bb94e82e3e2108abbe3e43e6230689273f756cd/lib/
[marco@lorenz lib]$ nm -C libboost_log.a | grep put_integer
0000000000000000 W void boost::log::v2s_mt_posix::aux::put_integer<char>(std::basic_string<char, std::char_traits<char>, std::allocator<char> >&, unsigned int, unsigned int, char)
0000000000000000 W void boost::log::v2s_mt_posix::aux::put_integer<wchar_t>(std::basic_string<wchar_t, std::char_traits<wchar_t>, std::allocator<wchar_t> >&, unsigned int, unsigned int, wchar_t)

Note that the signature of the functions vary on the string type; it's looking for std::__cxx11::basic_string but @lasote's build has std::basic_string. In a naive analysis, this seems to imply that boost was built without C++ 11?

However, I'm still very puzzled as to why it works on your VM. To be honest, you don't have to link everything, just do make utility_spec. If that works then you've gone further than me, and that then puts into question the entire theory of boost being built with C++ 03.

[mcraveiro]

hm, which kind of makes me think that we need yet another "variable" to keep track of in terms of conan packaging: which "mode" the compiler was in. C++11 is not compatible with C++-03 in all cases ABI-wise [1], so the exact same code with the exact same standard library can produce different ABIs depending on the -std flag :-(

[1] https://lists.debian.org/debian-devel/2013/08/msg00109.html

[mcraveiro]

Ok guys so my idea of building boost locally and trying to figure out if there was something wrong with the build also failed miserably [1]. I'm out of ideas I'm afraid :-( To recap the issue, dogen was building happily around build #785 [2], with the following packages:

    Boost/1.60.0@lasote/stable from conan.io
    bzip2/1.0.6@lasote/stable from conan.io
    libiconv/1.14@lasote/stable from conan.io
    libxml2/2.9.3@lasote/stable from conan.io
    zlib/1.2.8@lasote/stable from conan.io
Packages
    Boost/1.60.0@lasote/stable:7a415ecb019e0e4d63cb729d65a5e3c7d8aa56f2
    bzip2/1.0.6@lasote/stable:8801072512419e81591f241200852b30dfc04c4c
    libiconv/1.14@lasote/stable:0692fb2bd888ba708ca65670557c56d2e16851ed
    libxml2/2.9.3@lasote/stable:93b5193e58107fc7c1c92f29f37899dbffbe02b1
    zlib/1.2.8@lasote/stable:50391cb89a05721e6453f19b4291fdf69aef2cf3

We changed very little on build #785 [3] - update to a text file - and it suddenly failed to build. Packages are:

    Boost/1.60.0@lasote/stable from conan.io
    bzip2/1.0.6@lasote/stable from conan.io
    libiconv/1.14@lasote/stable from conan.io
    libxml2/2.9.3@lasote/stable from conan.io
    zlib/1.2.8@lasote/stable from conan.io
Packages
    Boost/1.60.0@lasote/stable:cf85d4b84c387675a5c97eafca404d5b882d2f74
    bzip2/1.0.6@lasote/stable:9340168e06a6c842321cfd1c7c914fbfc7267119
    libiconv/1.14@lasote/stable:0692fb2bd888ba708ca65670557c56d2e16851ed
    libxml2/2.9.3@lasote/stable:93b5193e58107fc7c1c92f29f37899dbffbe02b1
    zlib/1.2.8@lasote/stable:50391cb89a05721e6453f19b4291fdf69aef2cf3

Not quite sure why the change in behaviour :-( It's interesting to notice that the hashes in boost and bzip changed between builds, even though the boost version is the same, so there must have been a change in the way boost is built somehow.

I'll park this for now and leave travis red until I have more ideas...

Thanks for your help.

[1] https://github.com/lasote/conan-boost/issues/12
[2] https://travis-ci.org/DomainDrivenConsulting/dogen/builds/124875867
[3] https://travis-ci.org/DomainDrivenConsulting/dogen/builds/131264711

[mcraveiro]

Ok so I've continued to investigate this issue. To simplify things I decided to build my own boost outside of conan, zip it into DropBox[1] and unzip it in Travis. I built boost locally as follows:

./bootstrap.sh --prefix=/some/local/directory
./b2 define=_GLIBCXX_USE_CXX11_ABI=1 cxxflags=-std=c++14 -j5 -d+2

I can clearly see in the output that boost is using -std=c++14 and -D_GLIBCXX_USE_CXX11_ABI=1. I also defined _GLIBCXX_USE_CXX11_ABI in dogen:

    add_definitions(-D_GLIBCXX_USE_CXX11_ABI=1)

Finally, I also moved to Ubuntu Trusty rather than Precise, hoping that a more recent distro would help the matter. Surprisingly, these changes did not make any difference to the linking errors! [2]

Sample errors:

path.cpp:(.text+0x4fb9): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_mutate(unsigned long, unsigned long, char const*, unsigned long)'
path.cpp:(.text+0x5094): undefined reference to `std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::_M_erase(unsigned long, unsigned long)'

The plot continues to thicken!

Cheers

[1] https://dl.dropboxusercontent.com/u/541873/packages/dogen_deps_gcc_5.3_linux_amd64_v4.bz2
[2] https://travis-ci.org/DomainDrivenConsulting/dogen/builds/137485938

[mcraveiro]

Ok I think I finally understood the whole thing, described in a blog post [1]. My build is now green, albeit not yet using Conan [2].

cheers

[1] http://mcraveiro.blogspot.co.uk/2016/06/nerd-food-strange-case-of-undefined.html
[2] https://travis-ci.org/DomainDrivenConsulting/dogen/builds/137848143

[memsharded]

Very glad that you finally made it green! No problem if not using conan in it. I read your post, good job. You are right, some of the current conan packages might not be perfect, but it is also that some of them are being packaged by us, and we are not expert builders or the maintainers of the library. Even if we are not, I'd say that thanks to conan we are able to build packages for a large number of use cases. I am sure this will improve in the short future. So we keep focusing on the development of conan to provide the infrastructure to create packages, but not so much in content-creation, as it is too much.

Thanks very much for sharing, we will try to learn from it and integrate in conan boost packages, so they finally would work for your build with conan too. Cheers!

[mcraveiro]

Yes, totally right - and also the ABI transition is really a spanner in the works that had nothing at all to do with Conan really. If it weren't for it, there would have been no problem with Conan packages. What I intend to do now is to try to build conan-boost from 14.04 and upload it to my account; then subsequently build all my Travis dependencies there. I think I will prefix/postfix my packages with "travis" just so I know which ones are which. Once travis finally upgrades LTS all of this will go away.

Cheers

[memsharded]

Ok, great, thanks for telling! And please update with your progress. Cheers!

[rcmonitor]

It seemed that I have similar error with Conan 0.19.2.
I'm trying to integrate Conan with Clion.
So, I'm including conanbuildinfo.cmake from build directory as described here
After reloading project, Cmake from Clion gives an error:

CMake Error at build/conanbuildinfo.cmake:355 (message): Incorrect 'Visual Studio', is not the one detected by CMake: 'GNU' Call Stack (most recent call first): build/conanbuildinfo.cmake:116 (conan_check_compiler) CMakeLists.txt:13 (conan_basic_setup)

[memsharded]

Hi @rcmonitor , It seems the error is more related to your install settings:

• Most likely you are in a Win environment, and with Visual Studio installed. The first time you ran conan, it autodetected it, and store those as your default in your <userhome>/.conan/conan.conf file. You can check them and modify if you want
• When you install your project dependencies, you didn't provide any settings, like -s compiler=gcc, so it used your defaults (Visual Studio) to install dependencies
• CLion is configured to use the GNU/Gcc toolchain by default. When you build your project the cmake conan helpers detect that you are building with gcc, but your dependencies were installed for Visual Studio.

You should install your dependencies for the same settings. It is likely that many packages in conan.io will not provide binaries for Win Mingw/gcc, so you might need to build them from source (--build=missing)

[memsharded]

Seems this issue was stale for a long time. The libstdc++ issue was addressed and solved at that time, so I think this issue can be closed. Thanks!