conan profile show default or conan profile show <profile> if custom profile is in use)[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=7
compiler.libcxx=libstdc++11
build_type=Release
[options]
*:fPIC=True
*:shared=False
boost:shared=True
[build_requires]
[env]
conan remove -f boost/1.70.0@conan/stableconan install --build -o boost:shared=True boost/1.70.0@conan/stable$ cd ~/.conan/data/boost/1.70.0/conan/stable/package/5b61a950a8e504865808bd4e284db10c833b020f/lib
$ ls -1 libboost_*.so.*.*.*
libboost_atomic.so.1.71.0
libboost_chrono.so.1.71.0
libboost_container.so.1.71.0
libboost_context.so.1.71.0
libboost_contract.so.1.71.0
libboost_coroutine.so.1.71.0
libboost_date_time.so.1.71.0
libboost_fiber.so.1.71.0
libboost_filesystem.so.1.71.0
libboost_graph.so.1.71.0
libboost_iostreams.so.1.71.0
libboost_locale.so.1.71.0
libboost_log_setup.so.1.71.0
libboost_log.so.1.71.0
libboost_math_c99f.so.1.71.0
libboost_math_c99l.so.1.71.0
libboost_math_c99.so.1.71.0
libboost_math_tr1f.so.1.71.0
libboost_math_tr1l.so.1.71.0
libboost_math_tr1.so.1.71.0
libboost_prg_exec_monitor.so.1.71.0
libboost_program_options.so.1.71.0
libboost_random.so.1.71.0
libboost_regex.so.1.71.0
libboost_serialization.so.1.71.0
libboost_stacktrace_addr2line.so.1.71.0
libboost_stacktrace_backtrace.so.1.71.0
libboost_stacktrace_basic.so.1.71.0
libboost_stacktrace_noop.so.1.71.0
libboost_system.so.1.71.0
libboost_thread.so.1.71.0
libboost_timer.so.1.71.0
libboost_type_erasure.so.1.71.0
libboost_unit_test_framework.so.1.71.0
libboost_wave.so.1.71.0
libboost_wserialization.so.1.71.0
Prompt investigation reveals the problem in the patch bcp_namespace_issues.patch which obviously was generated against 1.71.0 and being incorrectly applied, replacing one extra line of context in Jamfile as well, which basically renames version 1.70.0 into 1.71.0.
Here is the relevant hunk from the aforementioned patch:
path-constant BOOST_ROOT : . ;
constant BOOST_VERSION : 1.71.0 ;
@@ -311,8 +312,8 @@ rule boost-install ( libraries * )
# stage and install targets via boost-install, above.
rule boost-lib ( name : sources * : requirements * : default-build * : usage-requirements * )
{
+ autolink = <link>shared:<define>BOOST_$(name:U)_DYN_LINK=1 ;
name = boost_$(name) ;
- autolink = <link>shared:<define>$(name:U)_DYN_LINK=1 ;
lib $(name)
: $(sources)
: $(requirements) $(autolink)
I think the hunk should get rejected in the first place because of context lines mismatch, and the patch should be rebased properly onto 1.70.0. But it ended up incorrectly applied by conan, seriously breaking the package.
For now, editing bcp_namespace_issues.patch on the line https://github.com/conan-io/conan-center-index/blob/5d3a76231eeab86d24dda08cb0ee92fa307ef50f/recipes/boost/all/patches/bcp_namespace_issues.patch#L23 to have constant BOOST_VERSION : 1.70.0 ; fixes the issue. So do just dropping the patch whatsoever.
hi @dorozhkin-stc
it turns out to be an issue in conan itself, see https://github.com/conan-io/conan/issues/5963
It seems all the linked issues have been resolved successfully, and fuzzy patch functionality merged in develop branch in conan main repo. Is this correct? Are the users supposed to wait for some next conan release and rebuild boost from community recipe themselves then, or they will get updated package automatically?
@dorozhkin-stc conan will now reject to apply fuzzy patches by default, as far as I understand
conan 1.21.0 is finally out and I've just tried building boost 1.70.0 from upstream recipe under recipes/boost/all using command conan create -o boost:shared=True . boost/1.70.0@xxx/testfix and it produced correct build (i.e. all shared objects have 1.70.0 in their names).
Furthermore, I checked existing binary packages at conan-center repo. Here are results:
boost/1.70.0 - it's completely OK
boost/1.70.0@conan/stable - still contains incorrectly named shared objects.
Is the latter reference is supposed to be rebuild or made obsolete and removed then?
the latter (boost/1.70.0@conan/stable) is obsolete and won't be rebuilt. it won't be removed, but won't receive any updates/fixes.
Okay, keeping that in mind, I think I can safely close the bug. Thank you for your work guys, appreciate that!
Just quick question:
What is this shorthand syntax of boost/1.70.0 vs boost/1.70.0@conan/stable that I've missed..?
Hi, @helmesjo
Conan supports references without user/channel since v1.18.0 and it is the way to go for libraries in conan-center. (all packages in conan-center-index follow this approach). The extra fields in the references should only be used to disambiguate, for example, if your company modifies a particular version of boost for its needs, it could be boost/<version>@mycompany/stable.
Oh, nice! Though, worth noting is that it's only experimental:
This is an experimental feature subject to breaking changes in future releases.
Which explains the the different errors I saw trying it just now.
Anyways, thanks!
It's experimental, yes, but please report any error you may come across.
Also, take into account that references with and without user/channel
correpond to two different packages, different recipes,...
El sáb., 21 dic. 2019 14:41, Fred Helmesjö notifications@github.com
escribió:
Oh, nice! Though, worth noting is that it's only experimental
https://docs.conan.io/en/latest/creating_packages/getting_started.html#omitting-user-channel
:This is an experimental feature subject to breaking changes in future
releases.Which explains the the different errors I saw trying it just now.
Anyways, thanks!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/conan-io/conan-center-index/issues/214?email_source=notifications&email_token=AAKXL6DZD3K6QMRFWJOARITQZYMJTA5CNFSM4JDM5TRKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEHO4JUA#issuecomment-568181968,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAKXL6FNZ4UIS3A4YRWAQILQZYMJTANCNFSM4JDM5TRA
.