Opened 9 years ago
Closed 8 years ago
#12408 closed Bug Report - General (Fixed)
mythtv fails to compile with Gentoo gcc 4.9
Reported by: | Owned by: | Karl Egly | |
---|---|---|---|
Priority: | minor | Milestone: | 0.27.6 |
Component: | MythTV - General | Version: | 0.27-fixes |
Severity: | medium | Keywords: | |
Cc: | Ticket locked: | no |
Description
See Gentoo bug: https://bugs.gentoo.org/show_bug.cgi?id=516692
mythtv apparently is missing some object files in the link stage which causes build problems in gcc 4.9:
Apart from mythavtest needs videobuffers.o,
- mythtranscode also needs videobuffers.o and
- mythtv-setup needs dtvmultiplex.o, dtvconfparser.so and dtvconfparserhelpers.o
I haven't personally reproduced this but probably could do so if necessary. Feel free to reach out to me with questions/etc. There was quite a bit of investigation as it was originally suspected to be a gcc issue, and escalated with them.
This was most recently tested with 0.27.4 at git commit 3b4390396bf09dfe3741508ecf7fc71a004abd01 on the fixes branch.
Attachments (2)
Change History (25)
comment:1 Changed 9 years ago by
Component: | MythTV - Mythfilldatabase → MythTV - General |
---|---|
Owner: | changed from stuartm to Isaac Richards |
Status: | new → assigned |
comment:2 Changed 9 years ago by
Owner: | Isaac Richards deleted |
---|---|
Status: | assigned → new |
comment:3 Changed 9 years ago by
comment:4 follow-up: 5 Changed 9 years ago by
Resolution: | → Works for me |
---|---|
Status: | new → closed |
Work for me with 4.9.2
comment:5 Changed 8 years ago by
Resolution: | Works for me |
---|---|
Status: | closed → new |
Replying to paulh:
Work for me with 4.9.2
I'm at a loss as to how a very clear issue of missing object files to the linking operation can be marked as "works for me" and closed. Frank Phillip's example shows that he is using lto when building. As the GCC maintainers explained in the bug (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63745) which introduces its own cans of worms but happens to work in this case for MythTV. But if you read they're analysis for the issue you will see that MythTV's build system is underlinking mythtranscode and mythtv-setup.
comment:6 Changed 8 years ago by
Any gentoo user able to provide a patch that fixes the underlinking?
It'll take some time here to build something to the point where I could even test for this.
Regards Stuart
comment:7 Changed 8 years ago by
I'd be happy to test a/o patch, but I was not able to reproduce this on my Gentoo boxes with gcc 4.9.3 installed. Are there any specific flags I should set to trigger this underlinking ?
Regards, Cédric
comment:8 Changed 8 years ago by
Having this exact problem with these Gentoo builds of MythTV:
Gentoo's gcc 4.9.3. CFLAGS="-march=amdfam10 -O2 -pipe". Here's the link command and its output:
x86_64-pc-linux-gnu-g++ -Wl,-O1 -o mythavtest main.o commandlineparser.o -L../../libs/libmyth -L../../libs/libmythtv -L../../external/FFmpeg/libavutil -L../../external/FFmpeg/libavcodec -L../../external/FFmpeg/libavformat -L../../external/FFmpeg/libswscale -L../../external/FFmpeg/libswresample -L../../libs/libmythbase -L../../libs/libmythui -L../../libs/libmythupnp -L../../libs/libmythmetadata -L../../libs/libmythservicecontracts -L../../libs/libmythprotoserver -lmythswscale -lmythavformat -lmythavcodec -lmythavutil -lmythswresample -lmythtv-0.27 -lmythupnp-0.27 -lmythbase-0.27 -lmythui-0.27 -lmyth-0.27 -lmythmetadata-0.27 -lmythservicecontracts-0.27 -lmythprotoserver-0.27 -L../../libs/libmythfreemheg -lmythfreemheg-0.27 -L../../external/libhdhomerun -lmythhdhomerun-0.27 -lXext -lXinerama -lXxf86vm -lXv -lXrandr -lX11 -lxml2 -lcrypto -lass -lfftw3_threads -lfftw3f -lfftw3 -lasound -lfreetype -lxvidcore -lx264 -lvpx -lvorbisenc -lvorbis -ltheoraenc -ltheoradec -logg -lmp3lame -lfaac -lm -ludev -luuid -pthread -lbz2 -lz -ldl -lraw1394 -liec61883 -lavc1394 -lrom1394 -L/var/tmp/portage/media-tv/mythtv-0.27.5_p20150904-r2/work/mythtv-0.27.5/mythtv/external/zeromq/src/.libs -lmythzmq -L/var/tmp/portage/media-tv/mythtv-0.27.5_p20150904-r2/work/mythtv-0.27.5/mythtv/external/nzmqt/src -lmythnzmqt -L/var/tmp/portage/media-tv/mythtv-0.27.5_p20150904-r2/work/mythtv-0.27.5/mythtv/external/qjson/lib -lmythqjson -L/usr/lib64 -L/usr/lib64/qt4 -lGL -lQtSql -L/usr/lib64/mysql -lQtXml -lQtOpenGL -lQtGui -lQtNetwork -lQtCore -lpthread main.o: In function `VideoOutput::StartDisplayingFrame()': /var/tmp/portage/media-tv/mythtv-0.27.5_p20150904-r2/work/mythtv-0.27.5/mythtv/programs/mythavtest/../../libs/libmythtv/videooutbase.h:199: undefined reference to `VideoBuffers::StartDisplayingFrame()' main.o: In function `VideoOutput::DoneDisplayingFrame(VideoFrame_*)': /var/tmp/portage/media-tv/mythtv-0.27.5_p20150904-r2/work/mythtv-0.27.5/mythtv/programs/mythavtest/../../libs/libmythtv/videooutbase.h:203: undefined reference to `VideoBuffers::DoneDisplayingFrame(VideoFrame_*)' main.o: In function `VideoOutput::StartDisplayingFrame()': /var/tmp/portage/media-tv/mythtv-0.27.5_p20150904-r2/work/mythtv-0.27.5/mythtv/programs/mythavtest/../../libs/libmythtv/videooutbase.h:199: undefined reference to `VideoBuffers::StartDisplayingFrame()' main.o: In function `VideoOutput::DoneDisplayingFrame(VideoFrame_*)': /var/tmp/portage/media-tv/mythtv-0.27.5_p20150904-r2/work/mythtv-0.27.5/mythtv/programs/mythavtest/../../libs/libmythtv/videooutbase.h:203: undefined reference to `VideoBuffers::DoneDisplayingFrame(VideoFrame_*)' collect2: error: ld returned 1 exit status Makefile:109: recipe for target 'mythavtest' failed make[2]: *** [mythavtest] Error 1 make[2]: Leaving directory '/var/tmp/portage/media-tv/mythtv-0.27.5_p20150904-r2/work/mythtv-0.27.5/mythtv/programs/mythavtest' Makefile:58: recipe for target 'sub-mythavtest-make_default' failed make[1]: *** [sub-mythavtest-make_default] Error 2 make[1]: Leaving directory '/var/tmp/portage/media-tv/mythtv-0.27.5_p20150904-r2/work/mythtv-0.27.5/mythtv/programs' Makefile:67: recipe for target 'programs' failed make: *** [programs] Error 2
Installed MythTV is 0.27_p20140321, and was probably built before the compiler was upgraded to the 4.9 series.
Going to attempt a patch.
Changed 8 years ago by
Attachment: | mythtv-0.27.5-modified-makefiles.tar.gz added |
---|
Modified makefiles to workaround Gentoo link bug
comment:9 Changed 8 years ago by
This is odd. It complains about undefined reference to VideoBuffers::StartDisplayingFrame
, but it's right there in the linked-in library:
# nm libmythtv-0.27.so | c++filt | grep VideoBuffers::StartDisplayingFrame 0000000000548000 t VideoBuffers::StartDisplayingFrame()
I've attached a tarball with the three modified Makefiles. All they do is add the aforementioned object files directly to the link line. This is a workaround, and not a real fix. This shouldn't be necessary since these objects are in the linked libraries. Unless, of course, whatever GCC's linker is doing ("devirtualization", I hear) is something it can't do across shared library boundaries.
Let me know if you want anything else tried.
comment:10 Changed 8 years ago by
Mike,
Can you provide a diff of what you changed rather than the changed Makefiles? Those makefiles are auto-generated so we'd need to distill the changes into the qmake files.
As far as the underlying issue, I bet it has something to do with the fact that its a static symbol and there's multiple callers and in fact the caller in question that's problematic is inside of a header file. I'm going to go with the GCC guys here who are saying that 4.9 is closer to the proper behavior while 4.8 and lower was not. Another workaround is to force people to use -flto.
comment:11 Changed 8 years ago by
Well, under the caveat that what I changed was a cheat... I can't work up an actual diff right now, but all I did was add the lines in the OBJS =
block that start with ../libs/libmythtv
. So grep
should show you exactly what I did. Which was literally the mods described in the OP. If this isn't good enough, I can probably cough up a diff tomorrow night.
That said, it's basically feeding the linker two copies of the same thing (one in the object file, another in libmythtv
) so while it builds, I can't say for sure it works. IMHO -fno-devirtualization
or -flto
are better workarounds.
Over in embedded land, I've seen a lot of things "break" in 4.9 and later that worked in 4.7 or earlier. One of them was even a bug that just happened to work close enough to right to escape detection. (Note: be careful when porting libraries from C-only developers.)
comment:12 Changed 8 years ago by
Are you trying to work around a broken compiler?
According to GCC's documentation (at https://gcc.gnu.org/onlinedocs/gccint/WHOPR.html ) the whole program optimization / link time optimization is supposed to work with C++ programs using shared libraries with inline functions in headers. So to me this is clearly a bug in their compiler / linker.
The referenced GCC bug (at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63745 ) appears to state the opposite in contradiction with that documentation.
I'm happy to apply a patch that moves the relevant function's implementation from the header to the implementation file if that helps Gentoo users.
comment:13 Changed 8 years ago by
dekarl,
The issue doesn't occur with -flto or -fwhole-program. The issue occurs only without that flag set. It appears that a number of distros are now using -flto by default which is why people aren't seeing that crop up there.
Changed 8 years ago by
Attachment: | mythtv-0.27.5-visibility.patch added |
---|
Patch fixing symbol visibility in shared object file for gcc-4.9. The patch was tested on my Gentoo system, but might not work with other compilers.
comment:15 Changed 8 years ago by
Good catch. I've rewritten it to use our macro. Looking forward to a success report.
comment:16 Changed 8 years ago by
dekarl,
I think maybe your fix needs s/mythexp.h/mythtvexp.h/
and s/MPUBLIC/MTV_PUBLIC/
Otherwise works for me backported to a custom build of 0.26 (don't ask) with gcc 4.9.3 on x86-64 (not Gentoo)
comment:20 Changed 8 years ago by
Milestone: | unknown → 0.27.6 |
---|---|
Status: | new → infoneeded_new |
I pushed the visibility fixes to fixes/0.27 please update and see if it actually fixes the issue as seen on Gentoo.
comment:21 Changed 8 years ago by
Owner: | set to Karl Egly |
---|
comment:22 Changed 8 years ago by
I've tested this in Gentoo and this works for me now. I've pushed out a new version in Gentoo that contains this update for all users.
comment:23 Changed 8 years ago by
Resolution: | → Fixed |
---|---|
Status: | infoneeded_new → closed |
Based on the previous comment, I'm going to close this as fixed
FWIW, I build latest 0.27-fixes all the time with gcc-4.9.2 on Arch Linux.
[fp@viron mythtv-fixes-git]$ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /build/gcc/src/gcc-4.9-20150304/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --disable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 4.9.2 20150304 (prerelease) (GCC)
Our gcc doesn't have any relevant patches. Let me know if you want me to check some things for you.