[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #53 from postmas...@conky-be.bounceio.net --- Created attachment 45108 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45108=edit attachment-117920-1.eml
[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #52 from postmas...@conky-be.bounceio.net --- Your email was bounced... - ... because something went wrong between you and your recipient. Ugh! What to do next? Well, your specific problem was a *5.1.2 * error. Which means you should: Check the "conky.be" part of "pav...@conky.be" for misspellings or missing letters. If you find an error, correct it in your contacts list or address book for next time. Or further: It is possible that the domain is temporarily inactive. If the spelling looks correct, contact your mail provider and if necessary, contact your recipient another way (e.g., phone or text message). Get more help on 5.1.2 errors here![1] Thanks, have a lovely day. Yours truly, betterbounces.net[2] Rate this email: Helpful[3] :) or... Not Helpful[4] :( Advertisement | Prefer no ads?[5] YOU MIGHT LIKE [6] [7] [8] Learn more about RevenueStripe...[9] - © 2017 betterbounces.net, All rights reserved. Privacy[10] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] 1. https://a.b-io.me/c/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZ2WYQAcUWdfxj5awgG9sVb8_Cd5cK5ANeO.IEzkK.uYaZBMvRT7Y9_R0.pxZUOMLOeEvQ67WwEjWSpv.fIbGMVztPrlhIrjkrYPTtLx7n8uUUxLPT_9Ws0H1uuQjjdY8otZeSxUSvAfdDgY7ejOcGXKQwk1.7TCaevkuEFAewhiu3AoU3Z2mJ8MY851JGPURbWxWDghqtbyhCAuvLcI3WN3Ca.zo1NwqjQppKoAALG6sPBNYg7e8XMS9A.yJrfSOQmCw3wt58UXoeQOSB8XpF1ji.SOs_JzOTh_jxc_I0WeA- 2. https://a.b-io.me/c/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZp75YYBzCAsbFWEhqkj6hmXSy9lHQVt0YxMJz0eZcNxcaRow_S4zLdIAOhFZmoDnoEXQS2JLdx4XstRAboUmTZYMVtiJgtncOeMdpW8ZCHde1szSYKUSFUZRP9kD8EJ1aeP8fWtMveK1FxSqrkaXDN9ZiqFi2CwrA 3. https://a.b-io.me/c/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZ2WYQAcUWdfyNQPwy8c.W4sID6tHoZkC_g_yuhxujPswL2TydbXkzrbXRAL6CW8oYv7hwHWJwSPVABg9QBSWeV9T1zP0Uwvnd51FciMElIKLuH5rn3PgpZp4B.7GYwuyfCFQLPGertDcDbqggI8KgIa5frSlJr.89MNYgzZnCxnu3AoU3Z2mJ8MY851JGPURbWxWDghqtbyhCAuvLcI3WN3Ca.zo1NwqjZSwwpJA2afzaD0ZoH8Bpv6EVYZ24p6WF5DxNGre2trVFs7Hk5loQdXDU5qAAcYOp0yrN48SXVUHXkPnaat9etrTOGBpQIUGH 4. https://a.b-io.me/c/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZ2WYQAcUWdfyNQPwy8c.W4sID6tHoZkC_g_yuhxujPswL2TydbXkzrbXRAL6CW8oYv7hwHWJwSPVABg9QBSWeV9T1zP0Uwvnd51FciMElIKLuH5rn3PgpZp4B.7GYwuyfCFQLPGertDcDbqggI8KgIW0PZrmbqwh.fRzETjbz1Z_2K1P3VYjXnSw_zivbLYA8gsXkVv4pjsmdZK_tM9D5EurOblYuJB.1qZI8tAftCBEit1ddWRcTT1TLYGEi7Tj.yH7uKojMxfRsiQaxrWwS48wLgDT5YF2DyK2IrGBcooWA8gRybSOl5cJLod3FRuBN 5. https://a.b-io.me/c/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZg6_ypgY0WDlQMsIYMGmmjmzq.cd5wQ3gxmfQEmRwABeUylOv2VLqSp12HlZAMtQNAWBcOKn73T3HAsIIGydUm.kU0V3LihEyi5qTxkYYTmZ6DD2EVRJKaj7tmNnhcNldTU_rEvVb4SK7tPyEWu_mycRIj0RXlwoJbrkkBvvgBWH5qCG5cYRaLz.y7Gzl_trFl7dzTYw5w8u2naqeluvlPptvAUQ0QR3Mtei9C68cHzhAkfhytJvxrT.R7_4PXPDYNg3ycv.tZjIW9xvdDf7YwKuymxBbZcte7kMtoBDwfm2XDEYwd9uD9.l4AtKdaDE6WSEvL7EwZYTAinuY5JiyP0OT0CgMAe9K44KpeiBE4rWg2_qxn4jYjQq4b1TtdivcqWEZpTvwwms7lQpTIJx_WSBfoF23e8QU0jGXJDpf433JpLEWL_iZBP5QF24RC36fynEYA5jvw5Kn7dHKAdiI4Qk_1D5f8BNpdyC560RQkF51r0i2tp95k0dMw9RD4ed6GYKls.oEbv.HBr6C6TKfNiJKEU_FT4N.51FciMElIKLuH5rn3PgpZp4B.7GYwuyfCFQLPGertDej3w_ONQBpbA-- 6. https://a.b-io.me/c/Y1lM9w9S1KeLJcXVUarv1OJFNUggPr2joqvuXnfzPULQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZKjzfoJuTwR0TS6q_0PFt_xTvenO_KUNEpUmBWVo0jroyTju34wY3k83Qy9KqqnrmbQxjAhjLLghxo_g7RBzHeaGy1BAuothz28tUpljMYjfydcYDss.ihRPyAPPU6qc49kQpB2yqLCdJfVPVPpUts1PEz0JpFpiyfNEnniQ88fcPjCsKk008Sz4vJppOoJnPMMPa4cdvfYVdv8U.SzNKsAk_1D5f8BNpdyC560RQkF51r0i2tp95k0dMw9RD4ed6GYKls.oEbv.HBr6C6TKfNiJKEU_FT4N.51FciMElIKLuH5rn3PgpZp4B.7GYwuyfCFQLPGertDej3w_ONQBpbA-- 7.
[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #51 from postmas...@conky-be.bounceio.net --- Your email was bounced... - ... because something went wrong between you and your recipient. Oh no! What to do next? Well, your specific problem was a *5.1.2 * error. Which means you should: Check the "conky.be" part of "pav...@conky.be" for misspellings or missing letters. If you find an error, correct it in your contacts list or address book for next time. Or further: It is possible that the domain is temporarily inactive. If the spelling looks correct, contact your mail provider and if necessary, contact your recipient another way (e.g., phone or text message). Get more help on 5.1.2 errors here![1] Thanks, have a lovely day. Yours truly, betterbounces.net[2] Rate this email: Helpful[3] :) or... Not Helpful[4] :( Advertisement | Prefer no ads?[5] Learn more about RevenueStripe... [6] [7] - © 2017 betterbounces.net, All rights reserved. Privacy[8] [IMAGE] [IMAGE] [IMAGE] [IMAGE] [IMAGE] 1. https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZ2WYQAcUWdfxj5awgG9sVb8_Cd5cK5ANeO.IEzkK.uYaZBMvRT7Y9_R0.pxZUOMLOeEvQ67WwEjWSpv.fIbGMVztPrlhIrjkrYPTtLx7n8uUUxLPT_9Ws0H1uuQjjdY8otZeSxUSvAfdDgY7ejOcGXKQwk1.7TCaevkuEFAewhiu3AoU3Z2mJ8MY851JGPURbWxWDghqtbyhCAuvLcI3WN3Ca.zo1NwqjQppKoAALG6u000Th8W6UhTVIf9pxofXym2Rh5ZgXtoz3zNAAmSz94VMZlodiXjtPh_jxc_I0WeA- 2. https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZp75YYBzCAsbFWEhqkj6hmXSy9lHQVt0YxMJz0eZcNxcaRow_S4zLdIAOhFZmoDnoEXQS2JLdx4XstRAboUmTZYMVtiJgtncOxc5gIFtvspHf3UmTnnF45u5mKINjIGQTgajbM2Aw.ogBtZHVwNPZ19ZiqFi2CwrA 3. https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZ2WYQAcUWdfyNQPwy8c.W4sID6tHoZkC_g_yuhxujPswL2TydbXkzrbXRAL6CW8oYv7hwHWJwSPVABg9QBSWeVxkVOXwv5HCofzdrNyfgjWC8BoZYRkw26JL6gIo0KvqK4yaWDpEo.RwDbqggI8KgIa5frSlJr.89MNYgzZnCxnu3AoU3Z2mJ8MY851JGPURbWxWDghqtbyhCAuvLcI3WN3Ca.zo1NwqjZSwwpJA2afzaD0ZoH8Bpv6EVYZ24p6WFF6clqi3kP3lO9mNumckmdfh1jah5D5BlGg5EOcVWVhRvfFqz4odt8bTOGBpQIUGH 4. https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZ2WYQAcUWdfyNQPwy8c.W4sID6tHoZkC_g_yuhxujPswL2TydbXkzrbXRAL6CW8oYv7hwHWJwSPVABg9QBSWeVxkVOXwv5HCofzdrNyfgjWC8BoZYRkw26JL6gIo0KvqK4yaWDpEo.RwDbqggI8KgIW0PZrmbqwh.fRzETjbz1Z_2K1P3VYjXnSw_zivbLYA8gsXkVv4pjsmdZK_tM9D5EurOblYuJB.1qZI8tAftCBEit1ddWRcTT1TLYGEi7Tj.gn8gVxz9bUAWiTJAQhRPebGBFf1M8IcH.l._I_tEb3Y0N.EvWPKc0MJLod3FRuBN 5. https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZg6_ypgY0WDlQMsIYMGmmjmzq.cd5wQ3gxmfQEmRwABfyd5wkEW426nttqOW5Ur.Hxmv0jqOfaK9v0.ELaZEJYeLQANwKCo5wi5qTxkYYTmZ6DD2EVRJKaj7tmNnhcNldTU_rEvVb4SK7tPyEWu_mycRIj0RXlwoJbrkkBvvgBWH5qCG5cYRaLz.y7Gzl_trFl7dzTYw5w8u2naqeluvlPptvAUQ0QR3Mtei9C68cHzhAkfhytJvxrT.R7_4PXPDYNg3ycv.tZjIW9xvdDf7YwKuymxBbZcte7kMtoBDwfm2XDEYwd9uD9.l4AtKdaDE6WSEvL7EwZYTAinuY5JiyP0OT0CgMAe9K44KpeiBE4rWg2_qxn4jYjSrZ.zg34r6KDdnCD_2bRjuSrPAr10H55865Cy.vUTsvTE96Oo05MGfVo8iTP_yjnwkYF1VHzwjsmqMbceeV6HCn7dHKAdiI4Qk_1D5f8BNpdyC560RQkF51r0i2tp95k0dMw9RD4ed6GYKls.oEbv.HBr6C6TKfNsBjhiWamoP9fzdrNyfgjWC8BoZYRkw26JL6gIo0KvqK4yaWDpEo.Ryj3w_ONQBpbA-- 6. https://a.b-io.me/c/Y1lM9w9S1Kcyhmff9PUym3lzb4DFXoKjbQxPz_NW_WrQaWlkIsfqBNRgrwhzFkMcrwIXvcetvsapa5zEDk5WGTHbtrbUNRnNPjFPAvfkQzIBqHpQlORFKA0Au_dTxrKSEM3LXaI3JD7fwAf4FSVvqDF.K_iHE4RwTSVvdmLIBNY7YexqWgPQg.7eMqYeRuGZzCFTlZ5zieJTlz6Kntx4wk.boz0f0v0vOzuVoMHqjxDZPGryGPm5DR80o108wYyBOmXlDHBZ1sY3PtFU6M1qwDL5GNtz7sgAFMSz0.vVrNAsxkpJYoCmieDNFbxEsaoHxBGL3a7F3rDHHgT1zGcKRJSW99fs8fCvHo223kNwGjhD4V.UeWvuoLkC5tXCniektXH5IlQ3z0DGxAo82dvf.egoYQy3mVjHoRVhnbinpYUXpyWqLeQ.eU72Y26ZySZ1_HWNqHkPkGUaDkQ5xVZWFG98WrPih23xtM4YGlAhQYc- 7.
[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #50 from Jonathan Wakely --- Author: redi Date: Tue Nov 27 23:25:56 2018 New Revision: 266533 URL: https://gcc.gnu.org/viewcvs?rev=266533=gcc=rev Log: PR libstdc++/67843 set shared_ptr lock policy at build-time This resolves a longstanding issue where the lock policy for shared_ptr reference counting depends on compilation options when the header is included, so that different -march options can cause ABI changes. For example, objects compiled with -march=armv7 will use atomics to synchronize reference counts, and objects compiled with -march=armv5t will use a mutex. That means the shared_ptr control block will have a different layout in different objects, causing ODR violations and undefined behaviour. This was the root cause of PR libstdc++/42734 as well as PR libstdc++/67843. The solution is to decide on the lock policy at build time, when libstdc++ is configured. The configure script checks for the availability of the necessary atomic built-ins for the target and fixes that choice permanently. Different -march flags used to compile user code will not cause changes to the lock policy. This results in an ABI change for certain compilations, but only where there was already an ABI incompatibility between the libstdc++.so library and objects built with an incompatible -march option. In general, this means a more stable ABI that isn't silently altered when -march flags make addition atomic ops available. To force a target to use "atomic" or "mutex" the new configure option --with-libstdcxx-lock-policy can be used. In order to turn ODR violations into linker errors, the uses of shared_ptr in filesystem directory iterators have been replaced with __shared_ptr, and explicit instantiations are declared. This ensures that object files using those types cannot link to libstdc++ libs unless they use the same lock policy. PR libstdc++/67843 * acinclude.m4 (GLIBCXX_ENABLE_LOCK_POLICY): Add new macro that defines _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY. * config.h.in: Regenerate. * configure: Regenerate. * configure.ac: Use GLIBCXX_ENABLE_LOCK_POLICY. * doc/xml/manual/configure.xml: Document new configure option. * include/bits/fs_dir.h (directory_iterator): Use __shared_ptr instead of shared_ptr. (recursive_directory_iterator): Likewise. (__shared_ptr<_Dir>): Add explicit instantiation declaration. (__shared_ptr): Likewise. * include/bits/shared_ptr_base.h (__allocate_shared, __make_shared): Add default template argument for _Lock_policy template parameter. * include/ext/concurrence.h (__default_lock_policy): Check macro _GLIBCXX_HAVE_ATOMIC_LOCK_POLICY instead of checking if the current target supports the builtins for compare-and-swap. * src/filesystem/std-dir.cc (__shared_ptr<_Dir>): Add explicit instantiation definition. (__shared_ptr): Likewise. (directory_iterator, recursive_directory_iterator): Use __make_shared instead of make_shared. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/config.h.in trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/doc/xml/manual/configure.xml trunk/libstdc++-v3/include/bits/fs_dir.h trunk/libstdc++-v3/include/bits/shared_ptr_base.h trunk/libstdc++-v3/include/ext/concurrence.h trunk/libstdc++-v3/src/filesystem/std-dir.cc
[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #49 from Jonathan Wakely --- std::thread no longer uses shared_ptr on trunk, so no longer depends on atomics and doesn't break if you mix objects compiled with and without native atomics, e.g. mixing objects built for i386 with objects built for i686, or mixing objects built for armv5 with objects built for armv7.
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #47 from Damien Buhl (daminetreg) damien.buhl at lecbna dot org --- So our GCC with the problem has been configured and built by yocto-poky the following way : ``` Using built-in specs. COLLECT_GCC=arm-poky-linux-gnueabi-gcc-4.8.1 COLLECT_LTO_WRAPPER=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi/gcc/arm-poky-linux-gnueabi/4.8.1/lto-wrapper Target: arm-poky-linux-gnueabi Configured with: /home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/work-shared/gcc-4.8.1-r0/gcc-4.8.1/configure --build=i686-linux --host=i686-linux --target=arm-poky-linux-gnueabi --prefix=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr --exec_prefix=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr --bindir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi --sbindir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/bin/armv7a-vfp-neon-poky-linux-gnueabi --libexecdir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/libexec/armv7a-vfp-neon-poky-linux-gnueabi --datadir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/share --sysconfdir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/etc --sharedstatedir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/com --localstatedir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/var --libdir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/lib/armv7a-vfp-neon-poky-linux-gnueabi --includedir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/include --oldincludedir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/include --infodir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/share/info --mandir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr/share/man --disable-silent-rules --disable-dependency-tracking --with-libtool-sysroot=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux --enable-clocale=generic --with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix --disable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu --enable-libstdcxx-pch --program-prefix=arm-poky-linux-gnueabi- --without-local-prefix --enable-target-optspace --enable-lto --enable-libssp --disable-bootstrap --disable-libmudflap --with-system-zlib --with-linker-hash-style=gnu --enable-linker-build-id --with-ppl=no --with-cloog=no --enable-checking=release --enable-cheaders=c_global --with-gxx-include-dir=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/ksp-0500/usr/include/c++ --with-sysroot=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/ksp-0500 --with-build-sysroot=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/ksp-0500 --enable-poison-system-directories --disable-libunwind-exceptions --with-mpfr=/home/buhldam/workspace/as521/workspace_original/product-modulo5-automation-as521/tmp/sysroots/i686-linux/usr --with-system-zlib --disable-nls Thread model: posix gcc version 4.8.1 (GCC) ``` We have now updated to 4.9.1, I'll tell you the bug still happens with 4.9.1. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #45 from Alexander Varnin --- (In reply to Damien Buhl (daminetreg) from comment #44) While given test works properly with -latomic on my installation, my application doesn't. It fails with segfault in approximately half of launches. Core dump points to some thread execution code. I suppose, it is still broken in some way. Replacing std::thread in my code with pthread_* makes it work properly. So I conclude, that this std::thread and atomic things is broken on my gcc 4.8.2 arm freescale imx53 yocto build. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #48 from Alexander Varnin fenixk19 at mail dot ru --- Created attachment 34224 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34224action=edit config.log for compiler with the bug Here is my config.log from cross compiler build.
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #43 from Alexander Varnin fenixk19 at mail dot ru --- And I also confirm that adding -latomic to build options fixes the issue.
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #44 from Damien Buhl (daminetreg) damien.buhl at lecbna dot org --- On a yocto built cross-toolchain adding -latomic didn't help. This may be due to the yocto cross-toolchain built without the support for some reason. I'll explorate it in deeper details. On 12/04/2014 01:52 PM, fenixk19 at mail dot ru wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #43 from Alexander Varnin fenixk19 at mail dot ru --- And I also confirm that adding -latomic to build options fixes the issue.
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #45 from Alexander Varnin fenixk19 at mail dot ru --- (In reply to Damien Buhl (daminetreg) from comment #44) While given test works properly with -latomic on my installation, my application doesn't. It fails with segfault in approximately half of launches. Core dump points to some thread execution code. I suppose, it is still broken in some way. Replacing std::thread in my code with pthread_* makes it work properly. So I conclude, that this std::thread and atomic things is broken on my gcc 4.8.2 arm freescale imx53 yocto build.
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #46 from Damien Buhl (daminetreg) damien.buhl at lecbna dot org --- As a pretier alternative you can use boost::thread with boost::atomic as backend as we did in a yocto cross toolchain with the same issue where latomic also segfaulted. Cheers fenixk19 at mail dot ru gcc-bugzi...@gcc.gnu.org a écrit : https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #45 from Alexander Varnin fenixk19 at mail dot ru --- (In reply to Damien Buhl (daminetreg) from comment #44) While given test works properly with -latomic on my installation, my application doesn't. It fails with segfault in approximately half of launches. Core dump points to some thread execution code. I suppose, it is still broken in some way. Replacing std::thread in my code with pthread_* makes it work properly. So I conclude, that this std::thread and atomic things is broken on my gcc 4.8.2 arm freescale imx53 yocto build. -- You are receiving this mail because: You are on the CC list for the bug.
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 Alexander Varnin fenixk19 at mail dot ru changed: What|Removed |Added CC||fenixk19 at mail dot ru --- Comment #42 from Alexander Varnin fenixk19 at mail dot ru --- I confirm an issue with G++ 4.8.2 and ARM platform. The platform is Freescale IMX53. OS build with yocto system using these instructions: https://github.com/Freescale/fsl-community-bsp-platform uname -a: Linux imx53qsb 2.6.35.3-gb51e9aa-dirty #34 PREEMPT Wed Dec 3 19:47:54 MSK 2014 armv7l GNU/Linux
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #41 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to Damien Buhl (daminetreg) from comment #40) I can also confirm the crash with gcc-4.8.1 for an arm platform. You'll have to provide more information about your compilation, see http://gcc.gnu.org/bugs.html You might need to link with -latomic on arm (I'm not sure)
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 Damien Buhl (daminetreg) damien.buhl at lecbna dot org changed: What|Removed |Added CC||damien.buhl at lecbna dot org --- Comment #40 from Damien Buhl (daminetreg) damien.buhl at lecbna dot org --- I can also confirm the crash with gcc-4.8.1 for an arm platform. Everything compiles fine, but on the platform the support for atomics looks like missing, because it dies with pure virtual method called. Using boost::thread which uses boost::atomic and in this case implements atomic self (not via the gcc compiler) is the only workaround I found without recompiling the compiler with atomic support.
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #39 from Paolo Carlini paolo.carlini at oracle dot com 2010-10-17 09:56:52 UTC --- I don't know exactly what we are doing in such headers but for sure if we have facilities which rely vitally on atomic builtins either should be disabled *completely* when the builtins are not actually available or the use of the builtins should be moved to functions exported by the .so (and then at build time either use as implementation details the atomic builtins or a slow fall back, like we do for string, more or less)
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #37 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-16 13:31:33 UTC --- What I was thinking of is that bits/c++config.h defines the following based on what was supported at the time the library is configured and built, not what is supported later when users compile: /* Define if builtin atomic operations for bool are supported on this host. */ #define _GLIBCXX_ATOMIC_BUILTINS_1 1 But I don't think thread depends on that. future and atomic do.
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #38 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-16 15:54:16 UTC --- I can confirm that this crash happens with GCC 4.4 when using -march=i386 But it isn't a problem with 4.5 and 4.6 because it fails to link $ ~/gcc/4.5/bin/g++ -std=c++0x t.cc -m32 -march=i386 -pthread /tmp/ccxpaful.o: In function `__gnu_cxx::__exchange_and_add(int volatile*, int)': t.cc:(.text+0x3c): undefined reference to `__sync_fetch_and_add_4' collect2: ld returned 1 exit status
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 Jacob McIntosh nacitar at gmail dot com changed: What|Removed |Added CC||nacitar at gmail dot com --- Comment #29 from Jacob McIntosh nacitar at gmail dot com 2010-10-15 18:46:05 UTC --- This bug is not invalid. If you build with g++ -std=c++0x -pthread -march=i386 whatever.cpp A binary built in this way exhibits the bug the reporter mentions. Also, on a 64-bit system g++ -std=c++0x -pthread -m32 -march=i386 whatever.cpp This also builds a binary with this issue. The -march is what you guys missed to trigger this issue. i486 works i586 works i686 works pentium4 works i386 exhibits the error mentioned by the reporter Tested with g++ 4.4.3 on a 32-bit mandrake system, a 64-bit gentoo system, and a 64-bit ubuntu system.
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Known to work|| --- Comment #30 from Andrew Pinski pinskia at gcc dot gnu.org 2010-10-15 18:48:54 UTC --- i386 does not have sync builtins. I wonder if doing -march=i386 changes the ABI ...
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #31 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-15 19:27:37 UTC --- ah, I see ... IIRC execute_native_thread_method uses shared_ptr which uses atomic builtins which are missing on i386 so yes, -march=i386 changes the ABI, you need to build libstdc++ with that -march switch
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #32 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-15 19:37:46 UTC --- I'm not sure -march=i386 explains the original report, since the OP said his compiler command was: $ g++ -std=c++0x -pthread thread.cc -o thread Does the front-end disable the HAVE_SYNC_COMPARE_AND_SWAP macros if you compile with (implicit or explicit) march=i386 ? If not, the library will think it can use builtins which aren't available. I seem to recall known issues arising from mismatches in -march options used when building and using the library.
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #33 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-15 19:45:22 UTC --- hmm, I should check, but I'm not home right now ... the problem could be that that the library only checks SYNC_HAVE_COMPARE_AND_SWAP t configure time, and (I think) pre-defines _GLIBCXX_ATOMIC_BUILTINS in config.h, which causes the library headers to think we have the sync builtins, even if the user later uses -march=i386 which disables them.
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #34 from Jacob McIntosh nacitar at gmail dot com 2010-10-15 19:46:56 UTC --- (In reply to comment #32) I'm not sure -march=i386 explains the original report, since the OP said his compiler command was: $ g++ -std=c++0x -pthread thread.cc -o thread Does the front-end disable the HAVE_SYNC_COMPARE_AND_SWAP macros if you compile with (implicit or explicit) march=i386 ? If not, the library will think it can use builtins which aren't available. I seem to recall known issues arising from mismatches in -march options used when building and using the library. Maybe by default, his gcc installation/configuration builds i386 (or some other arch that has the same problem even), and it didn't seem relevant to mention. I'm unsure how gcc determines its default, but that seems a likely scenario to me. And I can reproduce it by explicitly specifying i386, so I'm inclined to think this is the case.
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #35 from Jonathan Wakely redi at gcc dot gnu.org 2010-10-15 20:06:55 UTC --- (In reply to comment #34) (In reply to comment #32) I'm not sure -march=i386 explains the original report, since the OP said his compiler command was: $ g++ -std=c++0x -pthread thread.cc -o thread Does the front-end disable the HAVE_SYNC_COMPARE_AND_SWAP macros if you compile with (implicit or explicit) march=i386 ? If not, the library will think it can use builtins which aren't available. I seem to recall known issues arising from mismatches in -march options used when building and using the library. Maybe by default, his gcc installation/configuration builds i386 (or some other arch that has the same problem even), and it didn't seem relevant to mention. I'm unsure how gcc determines its default, but that seems a likely scenario to me. But in that case the library would have been configured and built with the same option, so every thing should match. And I can reproduce it by explicitly specifying i386, so I'm inclined to think this is the case. Yes, but then you have a mismatch between the already built libstdc++.so and the new objects you link to it. I'm not saying you're wrong, just that it *should* to work if you configure and build for the exact same target. It's less surprising (though still not good) if things fail when you mix'n'match, basically because i386 is crippled compared to other x86 targets.
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #36 from Paolo Carlini paolo.carlini at oracle dot com 2010-10-15 23:41:54 UTC --- (In reply to comment #32) Does the front-end disable the HAVE_SYNC_COMPARE_AND_SWAP macros if you compile with (implicit or explicit) march=i386 ? I'm jumping in just in case this point hasn't been clarified already: I added to the front end the __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* macros, and indeed, are sensitive to the *actual* command-line options: with -march=i386 are definitely undefined.
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #28 from paolo dot carlini at oracle dot com 2010-01-16 10:10 --- Feedback not forthcoming. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #21 from phil at nwl dot cc 2010-01-15 22:07 --- (In reply to comment #18) Just build everything with default configure options, then go inside the libstdc++-v3 *build* dir and type 'make check'. Ah, hmm. Well, having to compile everything in order to run the tests using an external compiler is a bit of a bummer, isn't it? Compiling will take some time on this X40, so please be patient. :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #22 from paolo dot carlini at oracle dot com 2010-01-15 22:15 --- (In reply to comment #21) (In reply to comment #18) Just build everything with default configure options, then go inside the libstdc++-v3 *build* dir and type 'make check'. Ah, hmm. Well, having to compile everything in order to run the tests using an external compiler is a bit of a bummer, isn't it? Maybe there is a communication problem here: I meant, *the whole GCC*, normally, with no special options, to keep things simple. If you want, you can exclude java, which normally takes a while, and fortran, and objective c, the languages you don't need in other terms: just pass --enable-languages=c++ and nothing else. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #23 from phil at nwl dot cc 2010-01-15 22:32 --- (In reply to comment #22) (In reply to comment #21) (In reply to comment #18) Just build everything with default configure options, then go inside the libstdc++-v3 *build* dir and type 'make check'. Ah, hmm. Well, having to compile everything in order to run the tests using an external compiler is a bit of a bummer, isn't it? Maybe there is a communication problem here: I meant, *the whole GCC*, Yes, it seems so. normally, with no special options, to keep things simple. If you want, you can exclude java, which normally takes a while, and fortran, and objective c, the languages you don't need in other terms: just pass --enable-languages=c++ and nothing else. What we want to do is to run the libstdc++ testsuite with my distribution-provided g++, in order to see whether it's generally broken or not, right? And what I'm criticising here is that I have to compile *anything* of the gcc-sources in order to run the testsuite. I see no sense in building any binaries at all, since I already have all binaries (executables as well as libraries) in order to run the tests?! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #24 from paolo dot carlini at oracle dot com 2010-01-15 23:07 --- (In reply to comment #23) What we want to do is to run the libstdc++ testsuite with my distribution-provided g++, in order to see whether it's generally broken or not, right? Wrong. You can't use one compiler (older, by the way), with a newer libstdc++. And what I'm criticising here is that I have to compile *anything* of the gcc-sources in order to run the testsuite. I see no sense in building any binaries at all, since I already have all binaries (executables as well as libraries) in order to run the tests?! You don't, you *need* a complete new GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #26 from paolo dot carlini at oracle dot com 2010-01-16 00:05 --- Hey, I'm telling you the way we all library maintainers (like me) and users check the library: they all fetch everything (either mainline or 4_4-branch, or whatever) via svn, make, make check. Now you want to do something else, you want to check the compiler + library you have already installed, but your obviously missing the testsuite, because you didn't build it yourself. Now, you are on your own, because I have no idea how and where to fetch only the testsuite of the specific GCC you are running on the specific Linux you are running, and then adjust everything to run it with your already installed compiler, this is not the normal way we do those tests. To repeat, the point was checking that your Linux and your hardware are sane, because I told you already that we know **for sure** that on current (and no so current) machines and Ubuntu, OpenSUSE, Fedora, whatever, that snippet works perfectly fine and *much* more than it, a whole testsuite. So, it's up to you, I'll keep this open: if over the nest month or so you provide the testresults you get for either your specific GCC, current 4_4-branch, or current mainline on your OS + hardware, we can hope to make progress on your issue, otherwise nobody will commit suicide, and the issue will be simply closed for lack of meaningful feedback from submitter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #27 from phil at nwl dot cc 2010-01-16 01:08 --- (In reply to comment #26) Hey, I'm telling you the way we all library maintainers (like me) and users check the library: they all fetch everything (either mainline or 4_4-branch, or whatever) via svn, make, make check. Now you want to do something else, you want to check the compiler + library you have already installed, but your obviously missing the testsuite, because you didn't build it yourself. Now, you are on your own, because I have no idea how and where to fetch only the testsuite of the specific GCC you are running on the specific Linux you are running, and then adjust everything to run it with your already installed compiler, this is not the normal way we do those tests. To repeat, the point was checking that your Linux and your hardware are sane, because I told you already that we know **for sure** that on current (and no so current) machines and Ubuntu, OpenSUSE, Fedora, whatever, that snippet works perfectly fine and *much* more than it, a whole testsuite. So, it's up to you, I'll keep this open: if over the nest month or so you provide the testresults you get for either your specific GCC, current 4_4-branch, or current mainline on your OS + hardware, we can hope to make progress on your issue, otherwise nobody will commit suicide, and the issue will be simply closed for lack of meaningful feedback from submitter. It's ok man, no offense here. I really didn't want to stomp on any feet. All I'm trying to do is to figure out why I'm having this problem and how to fix it. Abusing this bug tracker for a little conversation was a pleasure to me, getting you upset wasn't my intention. My apologies for that. So I will just do as you say and try to fix my distribution (or bug it's maintainers) instead of getting into your way. Anyway, thanks a lot for your help so far. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
-- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #16 from phil at nwl dot cc 2010-01-15 01:49 ---
(In reply to comment #14)
I'll give the testsuite a try, but this will take some time (svn checkout is
still running).
Oh boy, here it comes. I hope I've done the right thing, as there is little
documentation about how to run the testsuite ('make check-g++' seems not to
work for testing out-of-tree-binaries).
What I did:
- checkout svn://gcc.gnu.org/svn/gcc/trunk
- cd $checkout/gcc runtest --tool g++ --srcdir ./testsuite
(output files g++.{log,sum} follow as attachments)
I'll appreciate instructions if this was all useless. :)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #17 from phil at nwl dot cc 2010-01-15 01:55 ---
(In reply to comment #16)
(output files g++.{log,sum} follow as attachments)
Mkay, bugzilla doesn't like the big logs. Meanwhile, take these:
- http://nwl.cc/~n0-1/g++.log
- http://nwl.cc/~n0-1/g++.sum
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #18 from paolo dot carlini at oracle dot com 2010-01-15 02:00 --- Just build everything with default configure options, then go inside the libstdc++-v3 *build* dir and type 'make check'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #19 from paolo dot carlini at oracle dot com 2010-01-15 02:02 --- (we are not particularly interested in the g++ testresults, that this the results for the C++ front-end proper, we are interested in the library results) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #20 from paolo dot carlini at oracle dot com 2010-01-15 02:05 --- Normally should look, for your i686 target, like the final part of this: http://gcc.gnu.org/ml/gcc-testresults/2010-01/msg01263.html (please disregard the 23_containers failures, it's a temporary problem, will go away soon) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #1 from phil at nwl dot cc 2010-01-13 20:22 --- Created an attachment (id=19580) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19580action=view) preprocessor output generated by -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #2 from phil at nwl dot cc 2010-01-13 20:23 --- Created an attachment (id=19581) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19581action=view) assembly output generated by -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #3 from phil at nwl dot cc 2010-01-13 20:23 --- Created an attachment (id=19582) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19582action=view) output when running the test program through valgrind -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-13 20:40 --- I cannot reproduce the problem in current 4_4-branch and mainline. Jon does it make any sense to you? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jwakely dot gcc at gmail dot ||com Known to work||4.4.3 4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #5 from redi at gcc dot gnu dot org 2010-01-13 21:33 --- It would be a lot easier to view the attachments if they were labelled as text files, but no, I can't see how this can happen. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #6 from redi at gcc dot gnu dot org 2010-01-13 21:37 --- does the g++ binary, gcc (GCC) 4.4.2 20091208 (prerelease), match the shared library, /usr/lib/libstdc++.so.6.0.13? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #7 from phil at nwl dot cc 2010-01-13 22:34 --- (In reply to comment #6) does the g++ binary, gcc (GCC) 4.4.2 20091208 (prerelease), match the shared library, /usr/lib/libstdc++.so.6.0.13? Yes, it does. The executable is linked against libstdc++.so.6, being a symlink to libstdc++.so.6.0.13. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #8 from phil at nwl dot cc 2010-01-13 22:37 --- (In reply to comment #4) I cannot reproduce the problem in current 4_4-branch and mainline. Jon does it make any sense to you? It seems like this bug exists only on x86 machines, but I don't have any x86_64 machine with gcc-4.4 available to verify that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #9 from paolo dot carlini at oracle dot com 2010-01-13 22:39 --- But note that I can't reproduce it on x86_64 and -m32 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #10 from paolo dot carlini at oracle dot com 2010-01-13 22:40 --- -m64 (the default) is also fine, of course. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #11 from phil at nwl dot cc 2010-01-13 22:52 --- (In reply to comment #9) But note that I can't reproduce it on x86_64 and -m32 Was told that, too. So what can I do to support you? What additional information should I provide? I could probably setup some shell access to the faulty machine (have to setup some dyndns first, though). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #12 from paolo dot carlini at oracle dot com 2010-01-13 23:09 --- Before anything else, you should make sure your system is otherwise sane, I don't know Linux nuty and I have no idea if it's affected by specific issues. Thus, first, I would suggest you to run the testsuite, which among many other things includes lots of tests of the thread facilities, which should all pass on x86 and x86_64 linux, see the gcc-testresults mailing list. If thread were broken as seriously as you are reporting on the main Linux distros, we would definitely know by now, because the testsuite tests *much* more than your snippet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #13 from redi at gcc dot gnu dot org 2010-01-13 23:34 --- (In reply to comment #9) But note that I can't reproduce it on x86_64 and -m32 It is possible to build a non-multilib 32-bit-only compiler on x86_64 - HJ gave Benjamin the right configure commands recently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #14 from phil at nwl dot cc 2010-01-14 01:13 --- (In reply to comment #12) Before anything else, you should make sure your system is otherwise sane, I don't know Linux nuty and I have no idea if it's affected by specific issues. Believe it or not, nuty is actually the hostname of the system in question. ;) The distribution is Arch Linux. Thus, first, I would suggest you to run the testsuite, which among many other things includes lots of tests of the thread facilities, which should all pass on x86 and x86_64 linux, see the gcc-testresults mailing list. If thread were broken as seriously as you are reporting on the main Linux distros, we would definitely know by now, because the testsuite tests *much* more than your snippet. I'll give the testsuite a try, but this will take some time (svn checkout is still running). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
[Bug libstdc++/42734] trivial use of std::thread fails with pure virtual method called
--- Comment #15 from paolo dot carlini at oracle dot com 2010-01-14 01:58 --- (In reply to comment #14) Believe it or not, nuty is actually the hostname of the system in question. ;) The distribution is Arch Linux. Believe it or not, I don't know Arch Linux either ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734
