build failure on fedora 13 (and above)

Bug #592730 reported by Gen Zhang
18
This bug affects 3 people
Affects Status Importance Assigned to Milestone
Lightspark
Fix Released
Medium
Unassigned

Bug Description

Direct attempt to build on fedora 13 gives problems which look like they're to do with libdl.so

See: http://fedoraproject.org/wiki/UnderstandingDSOLinkChange

The required libraries need to be appended to the command line: -ldl -lGLU -lrt

I am not sure how cmake works, so cannot implement the change myself.

Revision history for this message
Alessandro Pignotti (a-pignotti) wrote :

thanks for the info

Changed in lightspark:
importance: Undecided → Medium
status: New → Confirmed
Revision history for this message
Gen Zhang (genneth) wrote :

Btw, there are a slew of other build errors on Fedora 13, which I take to be an indication that as various other distros upgrade these will start showing up a bit more. Shall I open a general fedora 13 build bug, or just continue here?

Also, all this building finally makes something that segfaults :-D is there any point in reporting that at the moment, or it is really too early to be helpful and just contributes noise?

Revision history for this message
Alessandro Pignotti (a-pignotti) wrote :

I think we may continue discussing fedora related issues here, I'm renaming the bug in a more general way. Random segfault are not supposed to happen anymore, so you should report them with a backtrace and some information about your system (such as CPU/video card/video driver). I'm currently using lightspark for my daily navigation and stability seems very good on my system.

summary: - build failure on fedora 13 (and above) due to changes in fedora linkage
+ build failure on fedora 13 (and above)
Revision history for this message
Alexandre Demers (oxalin) wrote :

In CMakeList.txt -ldl -lGLU -lrt have to be appended :
@@ -80,1 +80,1 @@IF(COMPILE_LIGHTSPARK OR COMPILE_TIGHTSPARK)
ADD_LIBRARY(spark STATIC ${LIBSPARK_SOURCES})
TARGET_LINK_LIBRARIES(spark ${lib_pthread} ${lib_glew} ${EXTRA_LIBS_LIBRARIES} ${ZLIB_LIBRARIES} ${LLVM_LIBS_CORE} ${LLVM_LIBS_JIT}
- ${SDL_LIBRARY} ${CURL_LIBRARIES})
+ ${SDL_LIBRARY} ${CURL_LIBRARIES} -ldl -lrt -lGLU)

---
But it my not be the best place to add it.

Revision history for this message
Alexandre Demers (oxalin) wrote :

Once this fix is applied, compilation runs well until the end where, on Fedora 13 64bit, an error occurs :
In file included from /usr/include/ffmpeg/libavutil/avutil.h:82,
                 from /usr/include/ffmpeg/libavcodec/avcodec.h:31,
                 from /home/ademers/Projects/lightspark/plugin-dir/../decoder.h:32,
                 from /home/ademers/Projects/lightspark/plugin-dir/../sound.h:26,
                 from /home/ademers/Projects/lightspark/plugin-dir/../swf.h:37,
                 from /home/ademers/Projects/lightspark/plugin-dir/plugin.h:32,
                 from /home/ademers/Projects/lightspark/plugin-dir/plugin.cpp:21:
/usr/include/ffmpeg/libavutil/common.h: In function ‘int32_t av_clipl_int32(int64_t)’:
/usr/include/ffmpeg/libavutil/common.h:154: error: ‘UINT64_C’ was not declared in this scope
make[2]: *** [plugin-dir/CMakeFiles/lightsparkplugin.dir/plugin.cpp.o] Error 1
make[1]: *** [plugin-dir/CMakeFiles/lightsparkplugin.dir/all] Error 2
make: *** [all] Error 2

It seems that ffmpeg introduced something new with version 0.6.
Anyway, the fix is the following as suggested in http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/2010-May/088083.html:
add __STDC_CONSTANT_MACROS define to fix a compilation error or add -D__STDC_CONSTANT_MACROS to the options of the compiler.

I tested both :
adding #define __STDC_CONSTANT_MACROS in plugin.h
or
adding -D__STDC_CONSTANT_MACROS in CMakeList.txt
@@ 57,1 @@
- SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wnon-virtual-dtor -Woverloaded-virtual -pipe ")
+ SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wnon-virtual-dtor -Woverloaded-virtual -pipe -D__STDC_CONSTANT_MACRO")

They both fix the problem. But it then pops another problem (which I'll describe in the next comment)

---
CPU Information
Processor (CPU): AMD Phenom(tm) 8450 Triple-Core Processor
  Speed: 1,050.00 MHz
  Cores: 3

Display Info
Vendor: Advanced Micro Devices, Inc.
  Model: Mesa DRI R600 (RS780 9610) 20090101 TCL DRI2
  Driver: 2.0 Mesa 7.8.1

Revision history for this message
Alexandre Demers (oxalin) wrote :

After adding the previous fixes, I get the following error :
Linking CXX shared library liblightsparkplugin.so
/usr/bin/ld: cannot find -lLLVMLinker
collect2: ld returned 1 exit status
make[2]: *** [plugin-dir/liblightsparkplugin.so] Error 1
make[1]: *** [plugin-dir/CMakeFiles/lightsparkplugin.dir/all] Error 2
make: *** [all] Error 2

But for that one, I have no fix to propose for now, I have to go at work.

Revision history for this message
Alexandre Demers (oxalin) wrote :

Well, I took the time needed and I found out that this bug was also flag under ArchLinux :
http://bbs.archlinux.org/viewtopic.php?id=97363

And they propose a fix to be added in CMakeList.txt after the "INCLUDE()"s:
SET(CMAKE_EXE_LINKER_FLAGS ${LLVM_LDFLAGS})
SET(CMAKE_SHARED_LINKER_FLAGS ${LLVM_LDFLAGS})

Then everything compiles to the end without any error. Tested on Fedora 13 64bit.

However, I don't know if it's usable.

Revision history for this message
Alexandre Demers (oxalin) wrote :

tested and... it crashed... by the way, the youtube player has been updated, so the readme should suggest doing the following to get the player :
wget http://s.ytimg.com/yt/swf/watch-vfl170492.swf

I suppose any bug related to crashes should be opened in another bug, so that's what I'll do.

Revision history for this message
Ed Marshall (esm) wrote :

Alexandre, thanks for getting building on F13 x86_64 as far along as you have! Your suggestions were spot-on; I just managed to get things built, but I'm segfaulting on the SWF you attached above:

(gdb) where
#0 0x00000039ea6329a5 in raise () from /lib64/libc.so.6
#1 0x00000039ea634185 in abort () from /lib64/libc.so.6
#2 0x00000039f16be8cd in __gnu_cxx::__verbose_terminate_handler() ()
   from /usr/lib64/libstdc++.so.6
#3 0x00000039f16bca56 in ?? () from /usr/lib64/libstdc++.so.6
#4 0x00000039f16bca83 in std::terminate() () from /usr/lib64/libstdc++.so.6
#5 0x00000039f16bcb7e in __cxa_throw () from /usr/lib64/libstdc++.so.6
#6 0x0000000000611a4e in lightspark::RenderThread::loadShaderPrograms (
    this=0x7fffffffda60) at /home/esm/lightspark/swf.cpp:1338
#7 0x00000000006125fd in lightspark::RenderThread::commonGLInit (
    this=0x7fffffffda60, width=480, height=387)
    at /home/esm/lightspark/swf.cpp:1485
#8 0x0000000000612bd6 in lightspark::RenderThread::sdl_worker (
    th=0x7fffffffda60) at /home/esm/lightspark/swf.cpp:1563
#9 0x00000039eb207761 in start_thread () from /lib64/libpthread.so.0
#10 0x00000039ea6e14dd in clone () from /lib64/libc.so.6

Since it appears to be shader-related, I'm tempted to blame my substandard video driver (ATI R300 driver for an RS690 card; there isn't even an fglrx build I can revert to anymore at this point); glxinfo doesn't show anything relating to shading. :(

So, I probably won't be able to help much more at this point, I think, but perhaps this will help?

Revision history for this message
Alessandro Pignotti (a-pignotti) wrote :

I've merged Alexandre's patch in git master with some modifications. It compiles on my fedora 13 VM. About the crashes, make sure you run make install after building to install shaders. Lightspark also search for ttf-liberation in the hard linked path /usr/share/fonts/truetype/ttf-liberation/LiberationSerif-Regular.ttf so create a symlink to the actual font or modify the hardlinked path in swf.cpp.

Changed in lightspark:
status: Confirmed → Fix Committed
Revision history for this message
Ed Marshall (esm) wrote :

A git pull and a rebuild later, it's building properly out of the box now. Thanks!

I'm still getting a segfault at runtime (after doing a make install this time):

(gdb) where
#0 0x00000039ea6329a5 in raise (sig=6)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1 0x00000039ea634185 in abort () at abort.c:92
#2 0x00000039f16be8cd in __gnu_cxx::__verbose_terminate_handler ()
    at ../../../../libstdc++-v3/libsupc++/vterminate.cc:93
#3 0x00000039f16bca56 in __cxxabiv1::__terminate (
    handler=<value optimized out>)
    at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:38
#4 0x00000039f16bca83 in std::terminate ()
    at ../../../../libstdc++-v3/libsupc++/eh_terminate.cc:48
#5 0x00000039f16bcb7e in __cxxabiv1::__cxa_throw (obj=0x7f8c4c3ad260,
    tinfo=<value optimized out>, dest=<value optimized out>)
    at ../../../../libstdc++-v3/libsupc++/eh_throw.cc:83
#6 0x00000000006124fe in lightspark::RenderThread::sdl_worker (
    th=0x7fff96b781b0) at /home/esm/lightspark/swf.cpp:1573
#7 0x00000039eb207761 in start_thread (arg=0x7f8c65bff710)
    at pthread_create.c:301
#8 0x00000039ea6e14dd in clone ()
    at ../sysdeps/unix/sysv/linux/x86_64/clone.S:115

Full output is attached.

Revision history for this message
Alessandro Pignotti (a-pignotti) wrote :

Lightspark expect ttf-liberation to be /usr/share/fonts/truetype/ttf-liberation/LiberationSerif-Regular.ttf, please create a symlink and the actual font and try again. Fontconfig support is a available on a contributor branch and will be merged soon

Changed in lightspark:
milestone: none → lightspark-0.4.2
Revision history for this message
Hicham HAOUARI (funnylife-ma) wrote :
Revision history for this message
Alexandre Demers (oxalin) wrote :

For those of you using Fedora 13, update GLEW packages to 1.5.4 from Rawhide : version 1.5.2-2 doesn't register correctly with a tool used by cmake to find needed packages.

I submitted a bug yesterday, hopefully this will be fixed at some point before Fedora 14.

Revision history for this message
Alexandre Demers (oxalin) wrote :
Revision history for this message
Hicham HAOUARI (funnylife-ma) wrote :

you can get binary binary i686 packages at :

http://hicham.fedorapeople.org/lightspark

Changed in lightspark:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.