directfb-config shows a lot of .o files which are clearly not included in the package. Should be .so instead. [01:59 AM][awjb@alkaid ~]$ directfb-config --cflags --libs --graphics=all --imageprovider=png,jpeg --input=keyboard --font=default -I/usr/include/directfb -D_GNU_SOURCE -D_REENTRANT -static /usr/lib64/directfb-0.9.24/systems/libdirectfb_fbdev.o /usr/lib64/directfb-0.9.24/wm/libdirectfbwm_default.o /usr/lib64/directfb-0.9.24/interfaces/IDirectFBFont/libidirectfbfont_default.o /usr/lib64/directfb-0.9.24/interfaces/IDirectFBImageProvider/libidirectfbimageprovider_png.o -lpng -lz -lm /usr/lib64/directfb-0.9.24/interfaces/IDirectFBImageProvider/libidirectfbimageprovider_jpeg.o -ljpeg /usr/lib64/directfb-0.9.24/inputdrivers/libdirectfb_keyboard.o /usr/lib64/directfb-0.9.24/gfxdrivers/libdirectfb_all.o -L/usr/lib64 -ldirectfb -lfusion -ldirect -lpthread -lz
I have fixed this here locally... would you mind me applying this patch? In addition: I created another option so that --graphics=all actually works. Seems sane to me not only to select one driver but to be able to query all drivers... And the last patch is about adding the different lib path to ld.so.conf.d otherwise compiling against them does not really do any good in a shared environment. Please let me know what you thing and if should apply the patches... Index: directfb.spec =================================================================== RCS file: /cvs/extras/rpms/directfb/FC-5/directfb.spec,v retrieving revision 1.10 diff -r1.10 directfb.spec 3c3 < Release: 5%{?dist} --- > Release: 6%{?dist} 9c9,12 < Source: http://www.directfb.org/download/DirectFB/DirectFB-%{version}.tar.gz --- > Source0: http://www.directfb.org/download/DirectFB/DirectFB-%{version}.tar.gz > Source1: directfb-32.conf > Source2: directfb-64.conf > Patch0: directfb-directfb-config.patch 18,19d20 < # libtool < BuildRequires: gcc-c++ 46a48 > %patch0 68a71,78 > mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/ld.so.conf.d/ > > %ifarch x86_64 > install -m 644 -p %{SOURCE2} $RPM_BUILD_ROOT%{_sysconfdir}/ld.so.conf.d/ > %else > install -m 644 -p %{SOURCE1} $RPM_BUILD_ROOT%{_sysconfdir}/ld.so.conf.d/ > %endif > 89a100 > %{_sysconfdir}/ld.so.conf.d/* 109a121,125 > * Sat Mar 25 2006 Andreas Bierfert <andreas.bierfert[AT]lowlatency.de> > - fix directfb-config (s/\.o/.so/) > - add --graphics=all switch to directfb-config > - add ld.so.conf.d files so all .so will be found >
Can you show me the patch please ? also, a test case to reproduce ? FWIW, my directfb-config doesn't do what yours did originally: [thomas@otto mach]$ directfb-config --cflags --libs --graphics=all -I/home/thomas/prefix//include/directfb -D_REENTRANT -L/home/thomas/prefix//lib -ldirectfb -lpthread -ldl -static -Wl,-udirectfb_fbdev -L/home/thomas/prefix//lib/directfb-0.9.18/gfxdrivers -Wl,-udirectfb_all -ldirectfb_all
Andreas, ping...
hm this was on x86_64... I will have to fire it up again later today to verify if this still is a problem there... seems like your reply got lost in my inbox so sorry for not answering...
Ping again, then :-) Removing FE6Target since 0.9.25.1 has just been rebuilt for FC6 and this bug has been filed against FC5. I'm not even sure I understand the bug... the library file extension is wrong on x86_64, is that it? But the part to have their location added to ld's search path seems wrong, as they are surely dlopen'ed, no?
Well the problem was this: I wanted to get splashy working and it needed directfb. But when talking to the config script a lot of things broke... probably because of this being on an x86_64... I will add the patch here so you can see what I mean :)
Created attachment 136484 [details] patch for directfb-config
Created attachment 136485 [details] 32bit conf
Created attachment 136486 [details] 64 bit
I can still see this in the latest 1.0.0-rc3 on Fedora 7 x86_64. The DirectFB guys state that this should be the last RC before the final release... could you maybe try and report this issue upstream in order to try and get it fixed before the 1.0.0 final? I'm sure they'd appreciate!
I've reported the issue upstream, including a link to this bug report.
This message is a reminder that Fedora 7 is nearing the end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 7. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '7'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 7's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 7 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. If possible, it is recommended that you try the newest available Fedora distribution to see if your bug still exists. Please read the Release Notes for the newest Fedora distribution to make sure it will meet your needs: http://docs.fedoraproject.org/release-notes/ The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 7 changed to end-of-life (EOL) status on June 13, 2008. Fedora 7 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.