Description of problem: I am having a problem with a package I am trying to bring to Fedora. It is called yafaray, a raytracer for blender: https://bugzilla.redhat.com/show_bug.cgi?id=467655 The bottom line is that it used to work fine until a certain version of Qt. After that, it no longer works in blender with the default Qt gui style. The fix is easy. It is just a question of changing the Qt gui style to, lets say, "Plastique", and then yafaray works fine with blender in KDE. However, even using qtconfig-qt4 to change the Qt gui style, it does not affect gnome, and yafaray just crashes blender in gnome in every attempt to render anything. Another point is how to make a Qt application use a different style in gnome? Version-Release number of selected component (if applicable): Qt 4.6.3 How reproducible: Always. Steps to Reproduce: 1. Load a project in blender 2. In render tab, select Yafaray export 0.1.1 3. Then press Render. Actual results: Blender Crashes ...... INFO: Adding World, type: Single Color added Background 'world_background' (constant)! INFO: Adding Render INFO: Adding Integrator: Direct lighting added Integrator 'default'! INFO: Adding Volume Integrator: None added Integrator 'volintegr'! creating new QApplication /usr/bin/blender: line 92: 30160 Segmentation fault /usr/bin/${blend}.bin $@ Expected results: A qt4 window with the scene being rendered. Additional info:
Can you provide a backtrace of the crash?
> The fix is easy. It is just a question of changing the Qt gui style to, lets > say, "Plastique", and then yafaray works fine with blender in KDE. That's not a fix, it's a crude workaround. We really need to figure out whether this is a bug in Yafaray, in the style or in Qt itself. Also, which style(s) does it not work with? The default styles in KDE and GNOME are different! (In KDE, Qt defaults to Oxygen, in GNOME to QGtkStyle.) And have you tried 4.7 yet? And a backtrace could really help us figure out what's going on. > However, even using qtconfig-qt4 to change the Qt gui style, it does not affect > gnome That looks like another bug to me.
Since I am at home now, the computers I have available at the moment are running F12 or F10. In Fedora 12, the only theme that crashes in KDE is GTK+ (qt 4.6.3, blender 2.49b), which makes me believe this is the theme being used in gnome. In Fedora 10, qt 4.5.3 and blender 2.49b, GTK+ also crashes blender, but changing to a theme different than GTK+ avoids the crash even in gnome.
The trace take us to gettext/GConf2/qt-x11 This was run on F12 using qt 4.6.3-8 --------------------------------------------------------- (gdb) thread apply all bt full Thread 1 (Thread 0x7ffff7fa2740 (LWP 3361)): #0 0x0000000000000000 in ?? () No symbol table info available. #1 0x00000037cd258a4a in g_hash_table_insert () from /usr/lib64/libgettextlib-0.17.so No symbol table info available. #2 0x00007fffe79d6b7c in gconf_client_get_default () from /usr/lib64/libgconf-2.so.4 No symbol table info available. #3 0x00000037d590207b in ?? () from /usr/lib64/libQtGui.so.4 No symbol table info available. #4 0x00000037d5625b38 in ?? () from /usr/lib64/libQtGui.so.4 No symbol table info available. #5 0x00000037d55b5e55 in QApplicationPrivate::construct(_XDisplay*, unsigned long, unsigned long) () from /usr/lib64/libQtGui.so.4 No symbol table info available. #6 0x00000037d55b6741 in QApplication::QApplication(int&, char**, int) () from /usr/lib64/libQtGui.so.4 No symbol table info available. ---Type <return> to continue, or q <return> to quit--- #7 0x00007fffee14c293 in initGui () at src/gui/mywindow.cc:61 argc = 0 #8 0x00007fffee800bf2 in _wrap_initGui (args=<value optimized out>) at build/bindings/renderwidget_wrap.cc:4028 resultobj = 0x0 #9 0x00000037e02dcbc2 in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 No symbol table info available. #10 0x00000037e02de61d in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0 No symbol table info available. #11 0x00000037e02dccef in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 No symbol table info available. #12 0x00000037e02de61d in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0 No symbol table info available. #13 0x00000037e02dccef in PyEval_EvalFrameEx () from /usr/lib64/libpython2.6.so.1.0 No symbol table info available. #14 0x00000037e02de61d in PyEval_EvalCodeEx () from /usr/lib64/libpython2.6.so.1.0 No symbol table info available. #15 0x00000037e026da00 in ?? () from /usr/lib64/libpython2.6.so.1.0 ---Type <return> to continue, or q <return> to quit--- No symbol table info available. #16 0x00000037e02439f3 in PyObject_Call () from /usr/lib64/libpython2.6.so.1.0 No symbol table info available. #17 0x00000037e02d6e53 in PyEval_CallObjectWithKeywords () from /usr/lib64/libpython2.6.so.1.0 No symbol table info available. #18 0x00000000008c2d79 in ?? () No symbol table info available. #19 0x00000000008c3409 in BPY_spacescript_do_pywin_event () No symbol table info available. #20 0x00000000006daf62 in winqreadscriptspace () No symbol table info available. #21 0x0000000000667e07 in screenmain () No symbol table info available. #22 0x0000000000564e23 in main () No symbol table info available.
I just upgraded gettext to 0.18.1.1 in Fedora 12 and recompiled blender, and that fixed the problem. I can use the qt GTK+ style just fine. Blender was the only application on my system depending on libgettextlib. I suppose an updated F13/F14 system will also work.
Still, having a useful backtrace would help us know where it happened exactly... See all those "in ... ?" we need to know *where* the backtrace leads in the code. Make sure the app itself is built with -g too, or has it's own -debuginfo installed too. debuginfo-install qt gettext python
#1 0x00000037cd258a4a in g_hash_table_insert () from /usr/lib64/libgettextlib-0.17.so This is a symbol conflict between gettextlib and glib2. The offending symbol is still present in /usr/lib/libgettextlib-0.18.1.so on my fully updated F13 system.
PS: The offending files come from: http://git.savannah.gnu.org/cgit/gettext.git/tree/gnulib-local/lib/glib which is gnulib's modified (and apparently binary-incompatible) copy of a few GLib modules, which in turn gets copied into gettextlib. This shows how copylibs are just broken.
Ping? Any solution in sight? The symbols should really get renamed in gettextlib (and upstream gnulib)!
Submitted bug upstream, https://savannah.gnu.org/bugs/index.php?32351 and sent message to gnulib-bugs list for advice, http://lists.gnu.org/archive/html/bug-gnulib/2011-02/threads.html (should show up shortly)
From the upstream bug: ---------------------------------- No executable or shared library outside the gettext package is supposed to link against libgettextlib or libgettextsrc. You need to find out (using 'ldd') which executable or library introduced the dependency to libgettextlib or libgettextsrc, and cut this dependency. The only libraries provided by gettext for use by other packages are libintl, libasprintf, and libgettextpo. ----------------------------------- repoquery --whatrequires 'libgettextlib-0.18.1.so()(64bit)' blender-0:2.49b-10.fc14.x86_64 blenderplayer-0:2.49b-10.fc14.x86_64 Looks like a blender bug then (re-assigning)
rebasing to f14, as confirmed on my own box.
The symbol conflict from gnulib is still a bug, mind you! (gettext isn't necessarily the only user of that stuff.) As is the fact that gettext-devel installs devel symlinks for a library you shouldn't link to. And gambas-runtime-0:1.0.19-13.fc14.i686 is also linked to libgettextlib.
Upstream (Bruno Haible) has this to say: *** begin quote *** > an unversioned .so symlink to link against still gets > installed for that library even if it makes no sense to link > it, presumably because libtool doesn't support installing only > the versioned file Yes. libtool does not distinguish "public" from "private" libraries. > it definitely is a bug in gnulib. You cannot assume that > gettextlib is the only place where that module will end up > used. No. The source code of g_hash_table_insert is in gettext/gnulib-local/lib/glib/ghash.c. This directory belongs to gettext, not gnulib. No package except the gettext package uses this source code. *** end quote *** So let's say that there's no bug in gnulib. QUESTION TO THE GETTEXT MAINTAINERS: Does anybody object if I change gettext in Rawhide to remove the libgettextlib.so and libgettextsrc.so symlinks from gettext-devel? (This has to be done in the specfile because libtool is not smart enough to allow doing this in the upstream sources.)
(In reply to comment #14) > Upstream (Bruno Haible) has this to say: > > *** begin quote *** > > an unversioned .so symlink to link against still gets > > installed for that library even if it makes no sense to link > > it, presumably because libtool doesn't support installing only > > the versioned file > > Yes. libtool does not distinguish "public" from "private" > libraries. Libtool does distinguish 'public' libraries and private ones. The latter is best known as a 'module'. Such module best live in a sub-directory of _libdir , outside of the standard link path. In this case it usually doesn't matter to have the SO versioned I don't know if this could apply to libgettextlib.so and libgettextsrc.so. But the fix proposed by Kevin make sense to me. And blender needs to be fixed, indeed.
Knowing all of that, fix blender is easy. 1) Change BR gettext-devel for gettext 2) Add these two lines to blender spec file, after setup: sed -i -e"s,gettextlib,,g" config/linux2-config.py sed -i -e"s,gettextlib,,g" user-config.py I recompiled blender and YafaRay is working with GTK+ style again ...
(In reply to comment #14) > QUESTION TO THE GETTEXT MAINTAINERS: Does anybody object if I change gettext in > Rawhide to remove the libgettextlib.so and libgettextsrc.so symlinks from > gettext-devel? (This has to be done in the specfile because libtool is not > smart enough to allow doing this in the upstream sources.) Thank you very much for helping to clear this up. I'm removing those symlinks in gettext-0.18.1.1-6.fc15.
(In reply to comment #16) > Knowing all of that, fix blender is easy. ... > I recompiled blender and YafaRay is working with GTK+ style again ... Can you request ACL on blender so you can commit it. Thx for having tracked this issue.
blender-2.49b-11.fc14 has been submitted as an update for Fedora 14. https://admin.fedoraproject.org/updates/blender-2.49b-11.fc14
blender-2.49b-11.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/blender-2.49b-11.fc13
As I pointed out in comment #13, gambas-runtime is also linked against libgettextlib; spot, can you please fix this so we can close this for good?
Hm. I'm not sure I can fix that, gambas-runtime is dependent on the gettext internals. It was previously bundling an old copy of gettext for this purpose. Aside from upstream saying "don't do that", is there an actual bug caused by gambas-runtime linking to libgettextlib ?
If any of the code linked (directly or indirectly) to libgettextlib is linking in glib2 (directly or indirectly) for any reason, the symbol conflict at issue here will be triggered.
Per this bug, there are symbol collisions with glib2 (which can lead to strange crashing)
gambas-runtime only links to: libc.so.6 libdl.so.2 libgettextlib-0.18.1.so libltdl.so.7 libm.so.6 So I do not think this is a problem. Gambas 1 is no longer maintained by the Gambas upstream, and Gambas 2 does not link to libgettextlib. In fact, I only keep gambas 1 around to support old gambas 1 applications, and there aren't very many of those anyways.
So I looked at gambas: AFAICT, the only reason gettextlib is required at all is this check in configure.in: GB_COMPONENT( gettext, GETTEXT, [external gettext library], [], [GB_FIND(gettextlib.$SHLIBEXT, /usr/local /usr, lib)], [-lgettextlib]) which your gambas-1.0.13-gettextfix.patch fixes to look for libgettextlib.$SHLIBEXT instead of gettextlib.$SHLIBEXT. But the only place this actually gets linked into is the gbx binary, and the only thing I see using gettext there is gbx_local.c which uses only <libintl.h>, so I don't see libgettextlib being actually needed. Try patching that check out. By the way, your specfile has a bogus BR qt-devel. What's actually being used there is qt3-devel, which is already dragged in by kdelibs3-devel (which is why this didn't get noticed).
> So I do not think this is a problem. I think this is a problem, because: 1. Gambas supports modules, which get loaded into the runtime and can link to anything. 2. gettext-devel no longer provides the symlink needed to link against libgettextlib, exactly because no application is supposed to link against it (and in fact, with blender fixed, gambas-runtime is the ONLY package linked against it).
The last time that package was built, it was a valid BR. :) Honestly, given that this is not a real problem for gambas 1, I'd rather not go poking about in an ancient compatibility package that is notoriously fragile as is.
blender-2.49b-11.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update blender'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/blender-2.49b-11.fc13
blender-2.49b-11.fc14 has been pushed to the Fedora 14 stable repository. If problems still persist, please make note of it in this bug report.
blender-2.49b-11.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.