-
-
Notifications
You must be signed in to change notification settings - Fork 209
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
Broken compilation with gcc v6.x if CXXFLAGS env var is set #155
Comments
Looks like a new compiler warning, which will break the compile if using the '-Werror' flag.
I guess adding 'no-terminate' warning flag would fix that. |
Thanks for the quick reply.
|
A. Reply:
No, it doesn't. export CFLAGS="-Wno-terminate ${CFLAGS}"
export CXXFLAGS="${CFLAGS}" What I don't understand is why it fails when an unharmful flag is given, like What makes this strange bug even more interesting that there are reports:
B. I found the issue:
So, setting export CFLAGS="-O2 ${CFLAGS}"
export CXXFLAGS="${CFLAGS}" Please note the the mentioned script uses I found out this by comparing the working and failing generated < CFLAGS = -pthread -pipe
---
> CFLAGS = -pthread
263c263
< CXXFLAGS = -pthread -pipe -g -DDEBUG -Wall -fvisibility=hidden
---
> CXXFLAGS = -pthread -g -O2 -g -DDEBUG -Wall -fvisibility=hidden C. Solution? If you can point out where I shall look I'll try to fix it. |
D. Solution:
This was removed from AC_DEFUN([TORRENT_CHECK_CXXFLAGS], [
AC_MSG_CHECKING([for user-defined CXXFLAGS])
if test -n "$CXXFLAGS"; then
AC_MSG_RESULT([user-defined "$CXXFLAGS"])
else
CXXFLAGS="-O2 -Wall"
AC_MSG_RESULT([default "$CXXFLAGS"])
fi
]) and the corresponding entry from TORRENT_CHECK_CXXFLAGS The result is with gcc 6.x (but probably it's a libtool "feature"):
export CFLAGS="${CFLAGS}"
export CXXFLAGS="${CFLAGS}" So, I suggest to put it back, it won't hurt anything. Ps:
And let me thank You for all the effort you put in the last ~13 years in this very versatile client! |
Please do. I'm still (slowly) working on the rtorrent-vagrant project to make some automated testing of different network configurations done. |
No worries. I'll do it during the weekend, carefully looking after other changes in scripts folder (maybe only the
:) I can imagine that it's a pain in the *** :) Don't give up, take your time! |
I have updated the fix:
The reason behind this is that set but empty flags shouldn't be specified at all. |
I still have this bug on my gentoo with GCC 6.4 and rtorrent 0.9.7/libtorrent 0.13.7
I had tried single thread build, but it changed nothing. |
It indeed looks the same problem. Did you have the Just for out of curiosity: can you compile rtorrent-ps-ch with it's build script? (I never worked with Gentoo, so try to make sure that all the package reqs are fulfilled.) |
No, I didn't have it. I added it, remerged libtorrent 0.13.7 and rtorrent 0.9.7 fine, now rtorrent works again. |
Couple of our users reported that they can't compile rtorrent-ps-ch on newer distros (not just on a particular one), one of them, @colinhd8 even came up with an unexpected fix:
unset the
CXXFLAGS
env var in our script. The only common thing amongst those distros is the gcc compiler version, which is v6.x .Since I wasn't sure where the actual issue relies (in our automagic function, other part of our script, etc.) I've created a minimal build script on fresh install of Debian 9 (using gcc v6.3.0) to see whether rtorrent can be built or not.
Conclusion: if the CXXFLAGS env var is set (even when it's empty string) building "fails" at the end of compilation process only when rtorrent tries to link libtorrent.so :
The same can be achieved earlier when rtorrent is configured with
xmlrpc
suppport: this time the checking macro fails at the biginning of building process of rtorrent: resulting the very same error message as above inconfig.log
.In summary:
CXXFLAGS
master
andfeature-bind
branches are affectedThis is a really nasty bug, e.g. in Gentoo such env vars can be defined system wide in
/etc/make.conf
. And that means no additional flags can be set in this way.I quickly went through the
configure.ac
and all them4
macros inscripts
dir but I didn't see anything unusual. More than that almost all the marcos are identical in rtorrent and libtorrent projects:so I'm not sure at all that rtorrent isn't affected by this, since libtorrent builds fine seemingly until it's not linked!
Maybe it would be worth to modify Travis scripts to:
Example distros that are affected:
The text was updated successfully, but these errors were encountered: