compilation failure when "--enable-utp" is used

[mr-4]

export 'LDFLAGS=-Wl,--as-needed'

export CFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fasynchronous-unwind-tables'

export CXXFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fasynchronous-unwind-tables'

export FFLAGS='-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -fasynchronous-unwind-tables -I/usr/lib/gfortran/modules'

./configure --prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-static --disable-gtk --disable-cli --disable-libcanberra --disable-nls --disable-libnotify --enable-daemon --enable-utp --with-gnu-ld LIBS=-L/usr/lib

Passes successfully:

Configuration:

Source code location: .

Compiler: g++

Build libtransmission: yes

• optimized for low-resource systems: no

• µTP enabled: yes

Build Command-Line client: no

Build GTK+ client: no

Optional dependencies for GTK+ client:

• dbus support: no

• gio for watchdir support: no

• libnotify for 'download completed' popups: no

• libcanberra for 'download completed' sounds: no

• gconf2 to register as a magnet link handler: no

• libappindicator for an Ubuntu-style tray: no

Build Daemon: yes

Build Mac client: no

Then during make I get the error attached to this bug. This to me indicates that somewhere in the Makefile in the uTP support (../third-party/*) directory is attempting to use gcc instead of g++ to compile c++ code.

If I rerun the whole process again without uTP support (i.e. with "--disable-utp" during ./configure) everything is OK and I can use transmission-daemon, though this is obviously without uTP support included (the main reason I wanted to get this version compiled and running).

[mr-4]

errors received during make

[jordan]

I'm not seeing this issue. What platform are you on, and which version of gcc/g++ are you using?

[mr-4]

Replying to jordan:

I'm not seeing this issue. What platform are you on, and which version of gcc/g++ are you using?

Transmission 1.30b2, Fedora Core 13 (kernel 2.6.35 though), arch is i686 (though I also tried to compile it on x86_64 with the same settings and kernel without success), gcc/g++ is 4.4.5.

[jordan]

Hmm, that's odd.

I've got a Fedora 13 box here (2.6.34.8-68.fc13.x86_64) with gcc 4.4.5 and it builds fine here. Could it be something odd with your environment?

If you like, I can pastebin my config.log for you s.t. you can diff it with your own.

[jordan]

Confirmed working on f14 as well. I suspect this is an issue with your system.

[x190]

​http://www.codebase.com/support/kb/?article=C01140

[mr-4]

Replying to x190:

​http://www.codebase.com/support/kb/?article=C01140

Interesting! I take it I need to add this flag (-lstdc++) to my LDFLAGS, right? If so I will try it out later and let you know if it worked.

[mr-4]

OK, I just had the time to get a closer look at what really is going on. As a comparison I have just compiled and build 2.22 (using the same environment) without any of the above problems.

By comparing the lines when the error happens in 2.30b2 and 2.22, where there is NO error, I was able to establish the following:

in 2.20 (where there are no errors):

======================================

/bin/sh ../libtool --tag=CC --mode=link gcc -I../third-party/dht -pthread -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=core2 -std=gnu99 -ggdb3 -Wall -W -Wpointer-arith -Wformat-security -Wcast-align -Wundef -Wcast-align -Wstrict-prototypes -Wmissing-declarations -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Wunused-parameter -Wwrite-strings -Winline -Wfloat-equal -Wextra -Wdeclaration-after-statement -Winit-self -Wvariadic-macros -m64 -Wl,--as-needed -o blocklist-test blocklist-test.o ./libtransmission.a ../third-party/miniupnp/libminiupnp.a ../third-party/libnatpmp/libnatpmp.a ../third-party/dht/libdht.a -lcurl -levent -lssl -lcrypto -ldl -lz -lm -L/usr/lib64

/bin/sh ../libtool --tag=CC --mode=link gcc -I../third-party/dht -pthread -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=core2 -std=gnu99 -ggdb3 -Wall -W -Wpointer-arith -Wformat-security -Wcast-align -Wundef -Wcast-align -Wstrict-prototypes -Wmissing-declarations -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Wunused-parameter -Wwrite-strings -Winline -Wfloat-equal -Wextra -Wdeclaration-after-statement -Winit-self -Wvariadic-macros -m64 -Wl,--as-needed -o bencode-test bencode-test.o ./libtransmission.a ../third-party/miniupnp/libminiupnp.a ../third-party/libnatpmp/libnatpmp.a ../third-party/dht/libdht.a -lcurl -levent -lssl -lcrypto -ldl -lz -lm -L/usr/lib64

libtool: link: gcc -I../third-party/dht -pthread -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=core2 -std=gnu99 -ggdb3 -Wall -W -Wpointer-arith -Wformat-security -Wcast-align -Wundef -Wcast-align -Wstrict-prototypes -Wmissing-declarations -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Wunused-parameter -Wwrite-strings -Winline -Wfloat-equal -Wextra -Wdeclaration-after-statement -Winit-self -Wvariadic-macros -m64 -Wl,--as-needed -o blocklist-test blocklist-test.o ./libtransmission.a ../third-party/miniupnp/libminiupnp.a ../third-party/libnatpmp/libnatpmp.a ../third-party/dht/libdht.a -lcurl -levent -lssl -lcrypto -ldl -lz -L/usr/lib64 -lm -pthread

======================================

In 2.30b2 (where there is an error):

======================================

/bin/sh ../libtool --tag=CC --mode=link gcc -I../third-party/dht -I../third-party/ -pthread -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=core2 -g -O0 -std=gnu99 -ggdb3 -Wall -W -Wpointer-arith -Wformat-security -Wcast-align -Wundef -Wcast-align -Wstrict-prototypes -Wmissing-declarations -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Wunused-parameter -Wwrite-strings -Winline -Wfloat-equal -Wextra -Wdeclaration-after-statement -Winit-self -Wvariadic-macros -m64 -Wl,--as-needed -o blocklist-test blocklist-test.o ./libtransmission.a ../third-party/miniupnp/libminiupnp.a ../third-party/libnatpmp/libnatpmp.a ../third-party/dht/libdht.a ../third-party/libutp/libutp.a -lrt -lcurl -levent -lssl -lcrypto -ldl -lz -lm -L/usr/lib64

/bin/sh ../libtool --tag=CC --mode=link gcc -I../third-party/dht -I../third-party/ -pthread -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=core2 -g -O0 -std=gnu99 -ggdb3 -Wall -W -Wpointer-arith -Wformat-security -Wcast-align -Wundef -Wcast-align -Wstrict-prototypes -Wmissing-declarations -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Wunused-parameter -Wwrite-strings -Winline -Wfloat-equal -Wextra -Wdeclaration-after-statement -Winit-self -Wvariadic-macros -m64 -Wl,--as-needed -o bencode-test bencode-test.o ./libtransmission.a ../third-party/miniupnp/libminiupnp.a ../third-party/libnatpmp/libnatpmp.a ../third-party/dht/libdht.a ../third-party/libutp/libutp.a -lrt -lcurl -levent -lssl -lcrypto -ldl -lz -lm -L/usr/lib64

libtool: link: gcc -I../third-party/dht -I../third-party/ -pthread -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=core2 -g -O0 -std=gnu99 -ggdb3 -Wall -W -Wpointer-arith -Wformat-security -Wcast-align -Wundef -Wcast-align -Wstrict-prototypes -Wmissing-declarations -Wmissing-format-attribute -Wredundant-decls -Wnested-externs -Wunused-parameter -Wwrite-strings -Winline -Wfloat-equal -Wextra -Wdeclaration-after-statement -Winit-self -Wvariadic-macros -m64 -Wl,--as-needed -o blocklist-test blocklist-test.o ./libtransmission.a ../third-party/miniupnp/libminiupnp.a ../third-party/libnatpmp/libnatpmp.a ../third-party/dht/libdht.a ../third-party/libutp/libutp.a -lrt -lcurl -levent -lssl -lcrypto -ldl -lz -L/usr/lib64 -lm -pthread

======================================

The difference between the above statements is the inclusion of 4 additional arguments in the 2.30b2 compilation/linking: "-I../third-party/", "-g -O0" (which conflicts with/replaces the "-g -O2" issued earlier), "../third-party/libutp/libutp.a" (that's understandable as utp support is new in 2.30b2) and "-lrt" (also not sure whether this is needed). When I attempted to compile 2.22 with additional pair of "-g -O0" and "-lrt" (passed to the linker) compilation succeeded!

Adding "LIBS=-lstdc++" to ./configure in 2.30b2 has indeed allowed me to build this version, though I am now going to revert to 2.22 as I am not happy with having a code build with no optimisation forced on it (-O0).

[jordan]

r12372: fix "gxx_personality_v0" error when compiling Transmission on some versions of gcc/g++

The problem is coming from gcc getting confused by having a C program (Transmission) link against a C++ library (libutp). In gcc, C++ code has an implicit dependency on libstdc++ for the gxx_personality_v0 function.

More info @ ​http://stackoverflow.com/questions/329059/what-is-gxx-personality-v0-for

[jordan]

This should resolve the issue, but since I'm not able to trigger it in the first place, mr-4 could you test r12372?

[mr-4]

Replying to jordan:

This should resolve the issue, but since I'm not able to trigger it in the first place, mr-4 could you test r12372?

Yeah, thanks! I will report back when I have the chance to run this (probably tonight, time permitting).

[jordan]

er13 wrote in #4200:

Many embedded systems use uClibc++ (and not the gcc' libstdc++) as an implementation of Standard C++ Library. r12372 breaks the compilation of transmission for such systems.

Please use CXX make variable to compile/link against libutp. Thanks!

[jordan]

r12374: revert r12372 based on feedback from er13: "Many embedded systems use uClibc++ (and not the gcc' libstdc++) as an implementation of Standard C++ Library. r12372 breaks the compilation of transmission for such systems."

[jordan]

Okay, after a bit of poking around I may have found an approach that will make everyone happy. er13, mr-4, could you both please test the link-using-cxx.diff and see if it works for you?

[er13]

After taking a closer look at the issue I would say the bug should simply be closed as invalid (@mr-4: sorry if it sounds a bit hard).

There is absolutely no need to link libstdc++ or uClibc++ in. From third-party/libutp/README.md

uTP is written in C++, but the external interface is strictly C (ANSI C89).

This is indeed so (from third-party/libutp/Makefile.am):

AM_CPPFLAGS = -fno-exceptions -fno-rtti -ansi -DPOSIX

By overriding CFLAGS and CXXFLAGS, and in particular using -fexceptions in it, you, mr-4, do introduce the dependency on the standard c++ library (i.e. libstdc++). So simply don't override the flags at all or make sure not to use those introducing the dependency on libstdc++.

[mr-4]

Replying to jordan:

Okay, after a bit of poking around I may have found an approach that will make everyone happy. er13, mr-4, could you both please test the link-using-cxx.diff and see if it works for you?

I can confirm that the patch works on both i686 and x86_64 platforms (including cross-compilation - x86_64->i686 and vice versa)!

I see from the logs that g++ is being used this time, instead of gcc, which is the right way of doing things.

However, I may stick with 2.22 as I am not happy with the "-g -O0" flags (tried to patch configure and configure.ac and remove them, but started getting a lot of warnings, so I might wait for the 2.30 release to come out, which is a great pity as I wanted to use this version to take advantage of uTP).

[mr-4]

Replying to er13:

By overriding CFLAGS and CXXFLAGS, and in particular using -fexceptions in it, you, mr-4, do introduce the dependency on the standard c++ library (i.e. libstdc++). So simply don't override the flags at all or make sure not to use those introducing the dependency on libstdc++.

This flag (-fexceptions) is there for a reason!

If uTP is designed in such a way that it needs to be compiled with -fno-exceptions so be it, but in any case the Transmission make system should be able to cater for this and also make sure that if I choose to use -fexceptions and protect my code I am able to without being forced to switch/not use that option in all of my code just for the sake of the uTP module (in all previous versions of Transmission I was able to do that without any problems, so I do not see a reason why that might change).

Again, to reiterate, if uTP needs to be compiled with -fno-exceptions then so be it, but do not force this option on the rest of the code (I am still baffled why are you not using g++ but insist on using gcc instead when compiling/linking)!

[mr-4]

Also, forgot to mention something else - by forcing -fno-exceptions on the entire source code you are likely to incur the wrath of quite a few distributors out there - Fedora for one - as they use -fexceptions in their rpm build system exclusively. If past experience with them is anything to go by, the distribution of this release is likely to be delayed as there would be a need for quite a lot of patching of the "official" code that needs to be done in order to ensure that option is used in the right places.

[mr-4]

Replying to er13:

After taking a closer look at the issue I would say the bug should simply be closed as invalid (@mr-4: sorry if it sounds a bit hard).

I disagree (see below).

[...]

By overriding CFLAGS and CXXFLAGS, and in particular using -fexceptions in it, you, mr-4, do introduce the dependency on the standard c++ library (i.e. libstdc++). So simply don't override the flags at all or make sure not to use those introducing the dependency on libstdc++.

I don't see how the patch, which jordan proposed "breaks" anything - it uses g++ instead of gcc to compile/link C++ code, which is the right way of doing things.

As g++ is used I don't see how this is going to "break" your (or mine) system - please explain?

In any case, I do not see why I should be forced to use -fno-exceptions in the rest of the code (or, to put it another way, to be prevented from using -fexceptions to protect my code if I want to) - give me one reason why this should be allowed?

[jordan]

Replying to er13:

By overriding CFLAGS and CXXFLAGS, and in particular using -fexceptions in it, you, mr-4, do introduce the dependency on the standard c++ library (i.e. libstdc++). So simply don't override the flags at all or make sure not to use those introducing the dependency on libstdc++.

Of course. You've hit the nail on the head. Thanks for pointing out that change in the build.

[jordan]

Replying to mr-4:

If uTP is designed in such a way that it needs to be compiled with -fno-exceptions so be it

uTP is designed with a C API, meaning it is intended to be callable from a C application. It doesn't have to be compiled with -fno-exceptions if, for example, the client code was also C++. That requirement is coming from the mixing of C++ library code and C client code.

but in any case the Transmission make system should be able to cater for this and also make sure that if I choose to use -fexceptions

What do you mean by protecting your code? libutp is statically linked and invoked by C code that doesn't understand throw/catch. In that situation, what is the use case for -fexceptions?

[jordan]

Replying to mr-4:

Also, forgot to mention something else - by forcing -fno-exceptions on the entire source code you are likely to incur the wrath of quite a few distributors out there - Fedora for one - as they use -fexceptions in their rpm build system exclusively.

citation needed

counterargument: ​http://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags

Adding to and overriding or filtering parts of these flags is permitted if there's a good reason to do so.

[mr-4]

Replying to jordan:

What do you mean by protecting your code? libutp is statically linked and invoked by C code that doesn't understand throw/catch. In that situation, what is the use case for -fexceptions?

I meant the rest of the Transmission code (outside the utp module), unless all of the Transmission code is written in C and not C++ (I haven't looked at it, so I can't be certain to be quite frank).

[jordan]

libutp is C++, the Mac GUI is Obj-C, and everything else is glorious C :)

[mr-4]

Replying to jordan:

citation needed

counterargument: ​http://fedoraproject.org/wiki/Packaging/Guidelines#Compiler_flags

Adding to and overriding or filtering parts of these flags is permitted if there's a good reason to do so.

Yeah, if there's good reason being the key here - trying to convince the people at Fedora is not always as straight forward as it first seems, trust me on this!

Anyway, I do not wish to veer off topic - If there is really no need for the -fexceptions flag anywhere in the Transmission code (i.e. there is no C++ code), then indeed it makes sense not to use it - simple as that really!

[mr-4]

Replying to jordan:

libutp is C++, the Mac GUI is Obj-C, and everything else is glorious C :)

Ah, well, case (bug) closed then, sorry for the noise! ;)

Also, I suppose there is no way I could easily "deactivate" IPv6 support in Transmission is there (I am referring to my other submission I've made - a feature request, not a bug)?

[jordan]

I'm not aware of any way to deactivate IPv6 and don't really see the use case.