http://bugzilla.rpmfusion.org/show_bug.cgi?id=459
--- Comment #10 from NicolasChauvet <kwizart(a)gmail.com> 2009-04-28 15:04:21 ---
Packaging a compiler isn't as trivial as any other packages.
I think it would be fine to have a project using the cuda compiler packaged as
an experiment. Do you have some candidate for this?
(I may have two cases, schroedinger-nonfree and nvidia-texture-tools).
Then I have few questions...
I have improved the spec file, but it remains two ways of improvements with
some related questions:
- Does binaries/libraries compiled with cuda 1.1 works with cuda 2.1 (2.2)
- Does the packaging scheme will work also for cuda 1.1 (which may remains
suitable for older systems/drivers), and forthcoming 2.2 (in other words, shall
we have version in the name, the same as java-1.6.0-{openjdk,sun} are
versionned).
- How the cuda compiler should works with the nvidia drivers Requirements.
(buildtime/runtime). That will make the cuda enabled libraries/(binaries?) to
be enabled once the driver support cuda with an additional sub-directory (the
same as glibc use dso from _libdir/sse2 when cpu support this feature). So
either this sub-directory need to be versioned (sugegstion: _libdir/cudart-2.1)
either we do not need that, (_libdir/cuda).
In Any case, produced libraries/binaries seems to be linked with the cudart
library from the cuda compiler, so this last needs to be splitted from the
compiler package to be installed independently.(as multilibs).
Produced binaries/libraries seems also to use symbols from the libcuda library
(provided from the nvidia driver) but aren't using -lcuda at link time, so
there are a lot of undefined-non-weak-symbol.
Then there is a need to mind the pkg-config buildtime behaviour along the WIP
improvements about nvidia drivers packaging.
(I will submit a new spec soon).
--
Configure bugmail:
http://bugzilla.rpmfusion.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.