New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Builds failing in GCC 5/new ABI #942

Closed
kyl191 opened this Issue Mar 26, 2015 · 6 comments

Comments

Projects
None yet
3 participants
@kyl191

kyl191 commented Mar 26, 2015

I'm having issues building ngx_pagespeed on Fedora Rawhide (aka Fedora 23), but not Fedora 19-22. I suspect the issue is steming from GCC 5's ABI change.

Full output of obj/autoconf.err: http://paste.fedoraproject.org/203083/27353406/, what I suspect is the relevant error below:

checking for psol
/tmp/ccWlcgjO.o: In function `base::BasicStringPiece<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::BasicStringPiece(char const*)':
autotest.cc:(.text._ZN4base16BasicStringPieceINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEC2EPKc[_ZN4base16BasicStringPieceINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEC5EPKc]+0x1f): undefined reference to `base::internal::StringPieceDetail<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::StringPieceDetail(char const*)'
/tmp/ccWlcgjO.o: In function `net_instaweb::HtmlParse::ParseText(base::BasicStringPiece<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > > const&)':
autotest.cc:(.text._ZN12net_instaweb9HtmlParse9ParseTextERKN4base16BasicStringPieceINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEE[_ZN12net_instaweb9HtmlParse9ParseTextERKN4base16BasicStringPieceINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEE]+0x29): undefined reference to `base::internal::StringPieceDetail<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::size() const'
autotest.cc:(.text._ZN12net_instaweb9HtmlParse9ParseTextERKN4base16BasicStringPieceINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEE[_ZN12net_instaweb9HtmlParse9ParseTextERKN4base16BasicStringPieceINSt7__cxx1112basic_stringIcSt11char_traitsIcESaIcEEEEE]+0x38): undefined reference to `base::internal::StringPieceDetail<std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> > >::data() const'
collect2: error: ld returned 1 exit status

The above linked article says to use the old ABI by specifying '-D_GLIBCXX_USE_CXX11_ABI=0'. Compiling ngx_pagespeed with
./configure --add-module=$HOME/ngx_pagespeed-release-1.9.32.3-beta --with-cc-opt="-D_GLIBCXX_USE_CXX11_ABI=0" works as expected.

I'm not too sure where the option should be added (documentation, somewhere in cpp_feature or config, ???), but can test & submit a pull request if someone can point a good location out.

@jeffkaufman

This comment has been minimized.

Show comment
Hide comment
@jeffkaufman

jeffkaufman Mar 26, 2015

Contributor

That makes sense. I think us documenting a requirement of -D_GLIBCXX_USE_CXX11_ABI=0 makes sense: we're usually the only c++ module people are compiling into nginx.

Contributor

jeffkaufman commented Mar 26, 2015

That makes sense. I think us documenting a requirement of -D_GLIBCXX_USE_CXX11_ABI=0 makes sense: we're usually the only c++ module people are compiling into nginx.

@jeffkaufman

This comment has been minimized.

Show comment
Hide comment
@jeffkaufman

jeffkaufman Mar 26, 2015

Contributor

Before updating the doc I need to make check whether old g++ chokes on D_GLIBCXX_USE_CXX11_ABI=0 or just ignores it.

Contributor

jeffkaufman commented Mar 26, 2015

Before updating the doc I need to make check whether old g++ chokes on D_GLIBCXX_USE_CXX11_ABI=0 or just ignores it.

@jeffkaufman

This comment has been minimized.

Show comment
Hide comment
@jeffkaufman

jeffkaufman Mar 26, 2015

Contributor

Checked with 4.8.1: passing in -D_GLIBCXX_USE_CXX11_ABI=0 is fine.

Contributor

jeffkaufman commented Mar 26, 2015

Checked with 4.8.1: passing in -D_GLIBCXX_USE_CXX11_ABI=0 is fine.

@kyl191

This comment has been minimized.

Show comment
Hide comment
@kyl191

kyl191 Mar 26, 2015

Building it for CentOS 6, 7 & Fedora 20-22+Rawhide worked just fine, that covers GCC 4.4.7-5.0

If it's just added in the documentation, it could be a footnote along the lines of "If you're compiling with GCC 5.0, add --with-cc-opt="-D_GLIBCXX_USE_CXX11_ABI=0". I don't think any other major distro is using GCC 5 yet, and Fedora 23 is only planned to be released in November, so there's ~8 months to think of something better.

kyl191 commented Mar 26, 2015

Building it for CentOS 6, 7 & Fedora 20-22+Rawhide worked just fine, that covers GCC 4.4.7-5.0

If it's just added in the documentation, it could be a footnote along the lines of "If you're compiling with GCC 5.0, add --with-cc-opt="-D_GLIBCXX_USE_CXX11_ABI=0". I don't think any other major distro is using GCC 5 yet, and Fedora 23 is only planned to be released in November, so there's ~8 months to think of something better.

@jeffkaufman

This comment has been minimized.

Show comment
Hide comment
@jeffkaufman

jeffkaufman Mar 26, 2015

Contributor

I'll plan to put --with-cc-opt="-D_GLIBCXX_USE_CXX11_ABI=0" in the documentation for now, and our next release will use nginx's config scripts to do the same thing.

Is there any reason to restrict the documentation note to people on 5.0 and above? Its easiest for users installing to just run the commands without having to look up versions.

Contributor

jeffkaufman commented Mar 26, 2015

I'll plan to put --with-cc-opt="-D_GLIBCXX_USE_CXX11_ABI=0" in the documentation for now, and our next release will use nginx's config scripts to do the same thing.

Is there any reason to restrict the documentation note to people on 5.0 and above? Its easiest for users installing to just run the commands without having to look up versions.

@kyl191

This comment has been minimized.

Show comment
Hide comment
@kyl191

kyl191 Mar 26, 2015

Very true - it would be marginally simpler to read until you're the one running GCC 5.

Yeah, there's no real reason not to include it as part of the command.

kyl191 commented Mar 26, 2015

Very true - it would be marginally simpler to read until you're the one running GCC 5.

Yeah, there's no real reason not to include it as part of the command.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment