Bug 255867 was accepted and the move of Cg to below /opt/ broke detection of Cg by 3rd party sources. (I.e. sources that are compiled *outside* portage.) The attached changed remedy that by: - symlinking to the 'Cg/' include directory from /usr/include/, allowing the headers to be found - augmenting LIBRARY_PATH with the Cg directory, allowing the libraries to be found.
Created attachment 184155 [details] ebuild additionally performing a symlink to the Cg include directory from /usr/include/ The important change is an one-liner: --- nvidia-cg-toolkit-2.1.0017.ebuild 2009-03-01 22:31:51.000000000 +0100 +++ nvidia-cg-toolkit-2.1.0017-r1.ebuild 2009-03-06 19:01:49.000000000 +0100 @@ -39,6 +39,7 @@ insinto ${DEST}/include/Cg doins usr/include/Cg/* + dosym ${DEST}/include/Cg /usr/include/Cg insinto ${DEST}/man/man3 doins usr/share/man/man3/*
Created attachment 184156 [details, diff] Add LIBRARY_PATH to 80cgc-opt Augments the LIBRARY_PATH env var.
Reassigning to graphics herd.
Created attachment 215230 [details] ebuild updated for latest Cg version
Is the include symlink hack still needed? ps2emu-zerogs (pcsx2-overlay) seems to build fine. Is the LIBRARY_PATH still needed? The env file sets LDPATH, which ends up adding to /etc/ld.so.cache, and hence there should be nothing else necessary.
Link with -L/opt/nvidia-cg-toolkit/lib and use includes by -I/opt/nvidia-cg-toolkit/include or -I/opt/nvidia-cg-toolkit/include/Cg. I don't see anything to fix here... closing.
(In reply to comment #6) > Link with -L/opt/nvidia-cg-toolkit/lib and use includes by > -I/opt/nvidia-cg-toolkit/include or -I/opt/nvidia-cg-toolkit/include/Cg. > > I don't see anything to fix here... closing. The point is that you should *not* have to do that. It was once possible to use Cg without specifying additional include or library directories, and that's how it should be.
(In reply to comment #7) > The point is that you should *not* have to do that. > It was once possible to use Cg without specifying additional include or library > directories, and that's how it should be. Nope, it's a binary-only library, therefore it should be hidden from scope of default paths compiler/linker looks it for. That's the whole point of moving it into /opt. Same applies to any binary-only package in tree. In fact, it's a gentoo quality and assurance policy.
Considering Cg is a library for _developers_, hiding it from the default compiler/linker paths pretty much goes against it's purpose. Also, I'm curious about the rationale of that policy, but I failed to find any information on it so far.
(In reply to comment #9) > Considering Cg is a library for _developers_, hiding it from the default > compiler/linker paths pretty much goes against it's purpose. just use the proper flags, developers should know howto do that :) > > Also, I'm curious about the rationale of that policy, but I failed to find any > information on it so far. > it boils down to: we can't guarantee what binary-only packages *actually* contain, and can't fix bugs from them either, so they should be hidden away in /opt
reopen to properly mark this as duplicate
*** This bug has been marked as a duplicate of bug 255867 ***