On Fri, 21 Mar 2008 18:31:54 -0400 Chuck Robey <[EMAIL PROTECTED]> wrote:
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > mdh wrote: > > --- Eduardo Cerejo <[EMAIL PROTECTED]> wrote: > > > >> My gcc is only looking in /usr/lib and /usr/include > >> for libraries and hearders and I added the paths > >> /usr/local/lib/ and /usr/local/include to my .cshrc > >> file: > >> > >> set path = (/sbin /bin /usr/sbin /usr/bin /usr/games > >> /usr/local/sbin /usr/local/bin /usr/local/lib > >> /usr/local/include $HOME/bin) > > > > PATH in the environment is where your shell searches > > for programs to run from the command line, system(), > > etc. This allows you to type, say, `sh` instead of > > having to type out `/bin/sh` or risking having > > `/home/somekiddie/sh` run instead when you type it. > > > >> but I still have to use gcc with -I and -L switch > >> for a program to compile or else it will fail. > >> > >> I'm using tcsh. > > > > There are two ways to set up alternate places to find > > libraries. The first is ldconfig, and you can see > > ports run this when you install a port containing > > shared libraries for example. The other is to use the > > LD_LIBRARY_PATH environment variable to set alternate > > paths at run-time. > > > > Well, that might be taken as confusing, even though your info is technically > quite correct. Both those methods WILL get those added dirs searched for > loading the libraries at run time, BUT it will NOT get your compiler to find > the > new paths, when linking the program during the build. I'm fairly sure that's > what the person wanted, don't you think so? > > Because, if I'm wrong, you can delete this email right here and now, read no > more. > > BUT you were quite correct, there are definitely *at least* two methods to set > up your *compiler* library search paths. In fact, I think I can show you 3 > methods right now. > > First, you can list the full path of the library on the command line, when you > use your compiler to link your program. > ] > Second, you can (as the person suggested himself) you can use the -l/-L > options > to bring in libraries & paths. The -L should come first, it adds the path, > and > the -l afterwards adds the specific library. > > The 3rd method is the use the variables LDFLAGS and LDADD. These variables > are > NOT 100% reliable to use, although they are fairly reliable on BSD systems. > The > LDFLAGS is where you put your "-LExtraPath" and the LDADD is where you stick > the -lExtraLibrary, like this (from a Makefile example): > LDFLAGS+=-L/usr/local > LDFLAGS+=-lgtk > > If you are using the BSD make util, the you use "+=" to add to your variables, > instead of replacing them, in case they had some values in them to begin with. > "Make" automatically adds in the obvious spaces, so your definitions don't > have > a train wreck for you. > > > The 'ldconfig(1)' man page has more info for you. > > > > Take care, mdh Here's what the book I'm reading says: The search paths for header files and libraries can also be controlled through environment variables in the shell. These may be set automatically for each session using the appropriate login file, such as \u2018.bash_profile\u2019 in the case of GNU Bash. Additional directories can be added to the include path using the environment variable C_INCLUDE_PATH (for C header files) or CPLUS_INCLUDE_PATH (for C++ header files). For example, the following commands will add \u2018/opt/gdbm-1.8.3/include\u2019 to the include path when compiling C programs: $ C_INCLUDE_PATH=/opt/gdbm-1.8.3/include $ export C_INCLUDE_PATH and similarly for C++ programs: $ CPLUS_INCLUDE_PATH=/opt/gdbm-1.8.3/include $ export CPLUS_INCLUDE_PATH This directory will be searched after any directories specified on the command line with the option -I, and before the standard default directories (such as \u2018/usr/local/include\u2019 and \u2018/usr/include\u2019). The shell command export is needed to make the environment variable available to programs outside the shell itself, such as the compiler--it is only needed once for each variable in each shell session, and can also be set in the appropriate login file.(8) Similarly, additional directories can be added to the link path using the environment variable LIBRARY_PATH. For example, the following commands will add \u2018/opt/gdbm-1.8.3/lib\u2019 to the link path: $ LIBRARY_PATH=/opt/gdbm-1.8.3/lib $ export LIBRARY_PATH This directory will be searched after any directories specified on the command line with the option -L, and before the standard default directories (such as \u2018/usr/local/lib\u2019 and \u2018/usr/lib\u2019). With the environment variable settings given above the program \u2018dbmain.c\u2019 can be compiled without the -I and -L options, $ gcc -Wall dbmain.c -lgdbm ------x-------- Now it looks like I can achieve what I want if I use bash, it looks like the export variable does the trick by making these paths available to external programs like gcc so basically I was trying to achieve this with the csh. _______________________________________________ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "[EMAIL PROTECTED]"
