From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 50A91138858 for ; Mon, 4 Feb 2013 16:42:22 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 7B619E02DF; Mon, 4 Feb 2013 16:42:12 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 0D545E0084 for ; Mon, 4 Feb 2013 16:42:10 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 36D5433DDFD for ; Mon, 4 Feb 2013 16:42:10 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Flag: NO X-Spam-Score: -0.111 X-Spam-Level: X-Spam-Status: No, score=-0.111 tagged_above=-999 required=5.5 tests=[AWL=-0.108, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=no Received: from smtp.gentoo.org ([IPv6:::ffff:127.0.0.1]) by localhost (smtp.gentoo.org [IPv6:::ffff:127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UbvF4WTrr48d for ; Mon, 4 Feb 2013 16:42:03 +0000 (UTC) Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) by smtp.gentoo.org (Postfix) with ESMTPS id 8A11A33DBAC for ; Mon, 4 Feb 2013 16:42:03 +0000 (UTC) Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1U2P7U-000211-23 for gentoo-user@gentoo.org; Mon, 04 Feb 2013 17:42:12 +0100 Received: from reg7.kyla.fi ([82.130.49.135]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Feb 2013 17:42:12 +0100 Received: from nunojsilva by reg7.kyla.fi with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 04 Feb 2013 17:42:12 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-user@lists.gentoo.org From: (Nuno Silva) Subject: [gentoo-user] Re: error: Cg/cg.h: No such file or directory Date: Mon, 04 Feb 2013 18:41:43 +0200 Message-ID: <87sj5cdoag.fsf@ist.utl.pt> References: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: reg7.kyla.fi User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) Cancel-Lock: sha1:qv7vjOK/TPX/GCzbdzEfHo0kDsY= X-Archives-Salt: 5a1ae6f5-6c92-4f3c-bd77-de1d135b2949 X-Archives-Hash: 91ab494d75e79c4295ca8457bfd55442 On 2013-02-03, João Matos wrote: > Dear list, > > I'm trying to build dolphin-emu from gamerlay, and I got the following > error: > > > error: Cg/cg.h: No such file or directory > > But the file actually exists: > > /opt/nvidia-cg-toolkit/include/Cg/cg.h > > Should it be a problem that I can solve myself? > > I thought so, than I've made a symlink for > /opt/nvidia-cg-toolkit/include/Cg at /usr/include. The compilation took a > little longer, but later, I've got the following: It took a little longer because it compiled, in fact the error occured so early that it failed without doing that much, I guess. > > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: > cannot find -lCg > /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/bin/ld: > cannot find -lCgGL It is some library detail: when configuring the makefiles to build some piece of source, the configure script needs to find the libraries and set *two* things from these libraries: - The include directories, to which it should append the /opt/nvidia-cg-toolkit/include path - The library directories, to which it should append a directory where nvidia-cg-toolkit has its libs This, at least for some packages, is done with pkg-config, see, for example, if you have gtk+-2.x on your system: pkg-config --cflags gtk+-2.0 This generates the right flags to pass to gcc when you want to compile a gtk+-2.x application. Likewise, --libs gives you the linker flags. Now what happened: you *did* provide it the header file, which is enough to compile the code part that depends on the nvidia library (compilation, which is modular, you can just go for parts of the code and information on other parts are on the header files), but you still need the library itself when you are assembling the final binary, so that the binary can be extended with information on where to get the library (or with the library itself, in the case of static linking). Although here --libs only gives me -l* for gtk, there is also a companion -L flag that, like -I for includes, sets the directories where the libraries can be found. I assue that, if -L is not given, that just means gtk+ is in the default locations. If you can figure out how to tell the configure script where to look for the libs, that would be the easiest thing to do; next to that, you can manually link the files using the right -L parameter or perhaps appending it to LD_LIBRARY_PATH when compiling. Perhaps try reinstalling nvidia-cg-toolkit after resyncing: some searches tell me there was yet another compilation breakage that got fixed recently: https://bugs.gentoo.org/show_bug.cgi?id=443546 But one person noted it does not work in amd64... I wonder if linking lib64 to lib there would work. -- Nuno Silva (aka njsg) http://njsg.sdf-eu.org/