Hi Denis, On Wednesday 29 November 2006 15:47, Attilio Fiandrotti wrote: > Last night, talking with Frans Pop and Kurt Roeckx, it turned out that > including correct libraries may be a bit complicated right now, and > possibly we could not make it in time for Etch. > So, i was asked to investigate about the possibility to remove > pthread_cancel() calls from DirectFB code: dok, do you believe that's > possible / easy to do?
I have just found a relatively simple (but not very clean) hack in the d-i build system that would allow us to include the libgcc_s library in gtk images for amd64 and that does solve the VT switching problems. Proper solutions require changes in non-d-i packages (creating a new udeb) that I doubt is realistic so short before the release of Etch. Especially as gcc one of the already frozen basic toolchain packages. However, as the solution is a hack, I'd prefer to avoid it. As you offered the option to take out the pthread_cancel() calls yourself, I assume that that is a realistic alternative. So I'd like to put the ball in your court. If removing the pthread_cancel() calls from directfb is not too invasive and does not cause any real regressions or coding problems, we'd appreciate if you could provide a patch for that (although I guess that also has packaging implications as it may cause an ABI change, so we need to discuss this with the Debian directfb maintainer too). If you'd prefer to leave the pthread_cancel() calls in, we can implement for Etch the hack that includes the libgcc_s library in g-i images for amd64 and work on a more structural solution after the release. For d-i people... The hack consists of adding a build dependency on libgcc1 for amd64 and adding a line 'EXTRAFILES = /lib/libgcc_s.so.1' (and a comment explaining the ugly hack) in the following files: installer/build/config/amd64/gtk-miniiso.cfg installer/build/config/amd64/cdrom/gtk.cfg installer/build/config/amd64/hd-media/gtk.cfg Cheers, FJP
pgpfIZgCMUBP1.pgp
Description: PGP signature
