Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
https://wiki.archlinux.org/title/Bug_reporting_guidelines
Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.
REPEAT: Do NOT report bugs for outdated packages!
FS#36566 - [glibc 2.18-1 / boost 1.54.0-2] int64_t conflict
Attached to Project:
Arch Linux
Opened by Johan R (cleanrock) - Friday, 16 August 2013, 15:55 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Sunday, 18 August 2013, 16:48 GMT
Opened by Johan R (cleanrock) - Friday, 16 August 2013, 15:55 GMT
Last edited by Bartłomiej Piotrowski (Barthalion) - Sunday, 18 August 2013, 16:48 GMT
|
DetailsDescription:
Removal of __GLIBC_HAVE_LONG_LONG from glibc causes boost to typedef int64_t wrong (long long) on x86_64. This problem should be fixed with boost 1.55, see https://svn.boost.org/trac/boost/ticket/8731 The bug report says it was removed in glibc 2.17 but i doubt that is correct for arch glibc 2.17. Steps to reproduce: the following cout << "int64_t " << typeid(int64_t).name() << endl; cout << "boost::int64_t " << typeid(boost::int64_t).name() << endl; produce int64_t l boost::int64_t x If i add #define __GLIBC_HAVE_LONG_LONG 1 it produce int64_t l boost::int64_t l |
This task depends upon
Closed by Bartłomiej Piotrowski (Barthalion)
Sunday, 18 August 2013, 16:48 GMT
Reason for closing: Fixed
Additional comments about closing: boost 1.54.0-3
Sunday, 18 August 2013, 16:48 GMT
Reason for closing: Fixed
Additional comments about closing: boost 1.54.0-3
Comment by Johan R (cleanrock) -
Friday, 16 August 2013, 16:03 GMT
I guess the best thing to do is to apply the boost patch: https://svn.boost.org/trac/boost/changeset/84950
Comment by Bart Janssens (bart_janssens) -
Saturday, 17 August 2013, 12:19 GMT
I second this, the error also induces linking errors with iostreams. I applied the patch locally and our project compiles fine again.