Summary: | The fftw-2.1.5-as-needed.patch of sci-libs/fftw-2.1.5-r1 causes librfftw to not be built | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Glenn Johnson <glennpj> |
Component: | [OLD] Library | Assignee: | Gentoo Science Related Packages <sci> |
Status: | RESOLVED FIXED | ||
Severity: | major | CC: | aballier, bugs, thedude0001, tom.los |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | Portage log file of fftw-2.1.5-r1 ebuild |
Description
Glenn Johnson
2006-11-01 11:38:31 UTC
Created attachment 100989 [details]
Portage log file of fftw-2.1.5-r1 ebuild
This is a log file of the ebuild of the fftw-2.1.5-r1 port as it exists in portage currently.
Hmm, everything works just fine here on my P4 with the patch. Could you please post what files fftw actually installs in /usr/lib! Note that, e.g., librfftw.so is actually a symlink to either libdrfftw.so or libsrfftw.so depending on your architecture. Thanks, Markus I'm now able to reproduce it, rfftw is not built if you build for the first time fftw but it is built if you already have fftw-2 installed. I'll try to investigate this. Alexis. Ok, so this was definitely not an easy one to understand. The problem is that, when adding the as-needed patch it adds interdependency between the libraries of fftw. Older bugged libtool versions did not handle this correctly and try to relink the library depending on another one during install phase (here, it tries to relink rfftw). Since we install the package in ${D}, it cannot link it correctly with -l{s,d}fftw and fails. The as-needed patch is "required" to build any program that wants to link to rfftw with as-needed, because, otherwise this will result in undefined symbols that are present in fftw but not in rfftw. The libtool bug is a known one, you can have a look at [1], [2] or [3]. The fix for this is to run "libtoolize --copy --force" to update the libtool files of fftw to non bugged ones. Running it in fftw-2.1.5-r1 ebuild between the epatch and econf lines works. Sorry for the as-needed patch that I sent, I didn't even think that such problems could appear. [1] http://lists.debian.org/debian-mentors/2000/10/msg00135.html [2] http://sources.redhat.com/ml/automake/2004-07/msg00126.html [3] http://svn.haxx.se/dev/archive-2003-04/0303.shtml Hi Alexis, Thanks a lot for tracking this down! I guess we should add an "_elibtoolize --copy --force" with _elibtoolize from autotools.eclass. I'll test this and update the ebuild as soon as I get to it. Thanks, Markus The fix works for me too so I added it to CVS as 2.1.5-r2. I am pushing this directly to stable since affected stable users might have a pretty hard time tracking the problem. (Some installations of 2.1.5-r1 will have librfftw and others not, for no obvious reason.) This is an example of why we should always revision bump ebuilds when adding "--as-needed" patches, even though most people seem to think otherwise. I commited that patch directly to the stable branch against my better judgment because I was asked to by many developers, and I now regret it. *** Bug 153404 has been marked as a duplicate of this bug. *** *** Bug 153346 has been marked as a duplicate of this bug. *** *** Bug 153186 has been marked as a duplicate of this bug. *** *** Bug 153882 has been marked as a duplicate of this bug. *** |