[1.34.0] failed to build on cygwin
I run "bjam install --toolset=gcc-3.4", and this is the output: Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). /cygdrive/c/My Documents/down_src/boost_1_34_0/tools/build/v2/build/virtual-target.jam:996: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <p/usr/local/lib>exact.dll.a error: previous virtual target { common%common.hard-link-exact.dll.a.IMPORT_LIB { common%common.copy-boost_signals-gcc34-mt-d-1_34.dll.a.IMPORT_LIB { gcc%gcc.link.dll-boost_signals-gcc34-mt-d-1_34.dll.a.IMPORT_LIB { gcc%gcc.compile.c++-trackable.o.OBJ { trackable.cpp.CPP } } { gcc%gcc.compile.c++-connection.o.OBJ { connection.cpp.CPP } } { gcc%gcc.compile.c++-named_slot_map.o.OBJ { named_slot_map.cpp.CPP } } { gcc%gcc.compile.c++-signal_base.o.OBJ { signal_base.cpp.CPP } } { gcc%gcc.compile.c++-slot.o.OBJ { slot.cpp.CPP } } } } } error: created from ./install-unversioned error: another virtual target { common%common.hard-link-exact.dll.a.IMPORT_LIB { common%common.copy-boost_prg_exec_monitor-gcc34-mt-d-1_34.dll.a.IMPORT_LIB { gcc%gcc.link.dll-boost_prg_exec_monitor-gcc34-mt-d-1_34.dll.a.IMPORT_LIB { gcc%gcc.compile.c++-execution_monitor.o.OBJ { execution_monitor.cpp.CPP } } { gcc%gcc.compile.c++-cpp_main.o.OBJ { cpp_main.cpp.CPP } } } } } error: created from ./install-unversioned error: added properties: <define>BOOST_TEST_DYN_LINK=1 error: removed properties: <define>BOOST_SIGNALS_DYN_LINK=1 <define>BOOST_SIGNALS_NO_LIB=1 /cygdrive/c/My Documents/down_src/boost_1_34_0/tools/build/v2/build/virtual-target.jam:459: in actualize-no-scanner from module object(file-target)@16511 /cygdrive/c/My Documents/down_src/boost_1_34_0/tools/build/v2/build/virtual-target.jam:111: in object(file-target)@16511.actualize from module object(file-target)@16511 /cygdrive/c/My Documents/down_src/boost_1_34_0/tools/build/v2/build-system.jam:476: in load from module build-system /cygdrive/c/My Documents/down_src/boost_1_34_0/tools/build/v2/kernel/modules.jam:261: in import from module modules /cygdrive/c/My Documents/down_src/boost_1_34_0/tools/build/v2/kernel/bootstrap.jam:132: in boost-build from module /cygdrive/c/My Documents/down_src/boost_1_34_0/boost-build.jam:9: in module scope from module
Atry wrote:
I run "bjam install --toolset=gcc-3.4", and this is the output:
Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). /cygdrive/c/My Documents/down_src/boost_1_34_0/tools/build/v2/build/virtual-target.jam:996: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <p/usr/local/lib>exact.dll.a error: previous virtual target { common%common.hard-link-exact.dll.a.IMPORT_LIB { common%common.copy-boost_signals-gcc34-mt-d-1_34.dll.a.IMPORT_LIB { gcc%gcc.link.dll-boost_signals-gcc34-mt-d-1_34.dll.a.IMPORT_LIB {
As discussed on IRC, this appears to be cygwin-specific bug, making build on cygwin impossible. Looks like one between RC3 and final release was a bit too hasty ;-) I believe the attached patch should fix the immediate problem. - Volodya
Vladimir Prus 写道:
Atry wrote:
I run "bjam install --toolset=gcc-3.4", and this is the output:
Building Boost.Regex with the optional Unicode/ICU support disabled. Please refer to the Boost.Regex documentation for more information (don't panic: this is a strictly optional feature). /cygdrive/c/My Documents/down_src/boost_1_34_0/tools/build/v2/build/virtual-target.jam:996: in virtual-target.register-actual-name from module virtual-target error: Duplicate name of actual target: <p/usr/local/lib>exact.dll.a error: previous virtual target { common%common.hard-link-exact.dll.a.IMPORT_LIB { common%common.copy-boost_signals-gcc34-mt-d-1_34.dll.a.IMPORT_LIB { gcc%gcc.link.dll-boost_signals-gcc34-mt-d-1_34.dll.a.IMPORT_LIB {
As discussed on IRC, this appears to be cygwin-specific bug, making build on cygwin impossible. Looks like one between RC3 and final release was a bit too hasty ;-)
I believe the attached patch should fix the immediate problem.
- Volodya
------------------------------------------------------------------------
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost Thanks. But I wonder why is this issue been reported one month ago still appeared now? http://lists.boost.org/Archives/boost/2007/04/119537.php
Atry wrote:
As discussed on IRC, this appears to be cygwin-specific bug, making build on cygwin impossible. Looks like one between RC3 and final release was a bit too hasty ;-)
I believe the attached patch should fix the immediate problem.
Thanks. But I wonder why is this issue been reported one month ago still appeared now? http://lists.boost.org/Archives/boost/2007/04/119537.php
Because we don't seem to have any procedure whatsoever in place that makes sure that incoming bug reports are classified with respect to impact on next release, and no procedures that make sure all critical issues are fixed before release? Lacking such procedures, it's easy for bugs to fall through the cracks. - Volodya
Vladimir Prus wrote:
Because we don't seem to have any procedure whatsoever in place that makes sure that incoming bug reports are classified with respect to impact on next release, and no procedures that make sure all critical issues are fixed before release?
Lacking such procedures, it's easy for bugs to fall through the cracks.
- Volodya
Trac's milestone tracking and tie-in with tickets provides this capability. Now there just needs to be a policy. Regards - -- ---------------------------------- Michael Caisse Object Modeling Designs www.objectmodelingdesigns.com
Vladimir Prus wrote:
Atry wrote:
As discussed on IRC, this appears to be cygwin-specific bug, making build on cygwin impossible. Looks like one between RC3 and final release was a bit too hasty ;-)
I believe the attached patch should fix the immediate problem.
Thanks. But I wonder why is this issue been reported one month ago still appeared now? http://lists.boost.org/Archives/boost/2007/04/119537.php
Looks like it wasn't an issue of haste.
Because we don't seem to have any procedure whatsoever in place that makes sure that incoming bug reports are classified with respect to impact on next release, and no procedures that make sure all critical issues are fixed before release?
Traditionally we did rely on every library maintainer doing exactly that tracking and making sure everything is in order for release for their own library. Providing regression tests as a help. This obviously does not work anymore. It's not procedures that's lacking the most. Thomas -- Thomas Witt witt@acm.org
Thomas Witt wrote:
Vladimir Prus wrote:
Atry wrote:
As discussed on IRC, this appears to be cygwin-specific bug, making build on cygwin impossible. Looks like one between RC3 and final release was a bit too hasty ;-)
I believe the attached patch should fix the immediate problem.
Thanks. But I wonder why is this issue been reported one month ago still appeared now? http://lists.boost.org/Archives/boost/2007/04/119537.php
Looks like it wasn't an issue of haste.
Because we don't seem to have any procedure whatsoever in place that makes sure that incoming bug reports are classified with respect to impact on next release, and no procedures that make sure all critical issues are fixed before release?
Traditionally we did rely on every library maintainer doing exactly that tracking and making sure everything is in order for release for their own library.
I'm not sure what you mean "traditionally". I think during earlier release cycles a somewhat proactive approach to dealing with issues was employed.
Providing regression tests as a help. This obviously does not work anymore.
It actually cannot work. Not all library maintainers are even available, and if they are available, it's not reasonable to expect that they read every single email, and therefore bug report that does not include "[some library name]" in subject will never reach the right person.
It's not procedures that's lacking the most.
Speaking about this particular cygwin bug, it's apparent that procedures are lacking. The current state is that 1.34 release fails to build on cygwin. There's a patch that seem to fix that, which took some 10 mins to do. So, why is 1.34 released without that fix? 1. While the bug was reported a month ago, it was not assigned to me, but to Rene. Why? Who did that assignment? 2. It was not noticed this bug is actually release critical. 3. The time to test release candidate was way to small, so this bug was reported for the second time immediately after 1.34 was released. May I also bring the example of optional? How comes that some critical bug was discovered day before hard code freeze? While you can also say it's the problem with individual developer, I'd say it's more result of lack of any procedures. While bugs are introduced and fixed by particular persons, most projects have mechanism to identify what bugs are critical for the next release, and nudge the right persons into fixing the *right* bugs. It's not exactly trivial to come with working procedures for Boost, due to great variety of components and target environments, but it still necessary to try. - Volodya
Vladimir Prus wrote:
May I also bring the example of optional? How comes that some critical bug was discovered day before hard code freeze?
I don't know what happened in that case, but sometimes bug reports just plain arrive at the most incomvenient times....
While bugs are introduced and fixed by particular persons, most projects have mechanism to identify what bugs are critical for the next release, and nudge the right persons into fixing the *right* bugs. It's not exactly trivial to come with working procedures for Boost, due to great variety of components and target environments, but it still necessary to try.
Hopefully Trac's milestones feature will help us get this in better order. John.
John Maddock wrote:
Vladimir Prus wrote:
May I also bring the example of optional? How comes that some critical bug was discovered day before hard code freeze?
I don't know what happened in that case, but sometimes bug reports just plain arrive at the most incomvenient times....
This happens. My impression is that it's not the case. And probably, we can alleviate this "inconvenient times" effect by introducing two deadlines -- for submitting bug reports, and for code changes, thereby nudging folks into submitting bug reports when there's still time to fix them.
While bugs are introduced and fixed by particular persons, most projects have mechanism to identify what bugs are critical for the next release, and nudge the right persons into fixing the *right* bugs. It's not exactly trivial to come with working procedures for Boost, due to great variety of components and target environments, but it still necessary to try.
Hopefully Trac's milestones feature will help us get this in better order.
That's my hope too. However, without some practices to make sure milestones are set, and without actually checking list of bugs assigned to milestone, that won't work. - Volodya
participants (5)
-
Atry -
John Maddock -
Michael Caisse -
Thomas Witt -
Vladimir Prus