How do I add search paths to gcc

[Chuck Robey]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Eduardo Cerejo wrote:
> On Fri, 21 Mar 2008 18:31:54 -0400
> Chuck Robey <chuckr at chuckr.org> wrote:
> 
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> mdh wrote:
>>> --- Eduardo Cerejo <ejcerejo at optonline.net> 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

No, I can't tell for certain if you know all the points or not, so I'm going to
h ave to assume you don't.  First point, there are NO variables that are always
automatically set, or can always be automatically used.  The ones I gave you
above (for the linking side of compiling) are most certaihnly the ones which are
most commonly used, BUT the real point of the matter is, for YOUR PARTICULAR
PROJECT, what did the person who wrote your project's Makefile use?  If they
used C_WHATSIT, then you'd have to to C_WHATSIT, no matter whatever garbage your
author has given you.  The two I gave, LDADD and LDFLAGS, are certainly quite
endemic on any BSD system, and I believe they are the most common even on Linux
systems, although less endemic there.  I'd never heard of the ones you gave, but
if someone used them in writing a Makefile, well, then they'd work, not the ones
I gave.

The idea is, the dependency lines in a makefile are given to the shell (normally
/bin/sh) to execute.  This never, ever means tcsh, even though you might be
using tcsh as your shell.  Sometimes Linux systems use bash as their sh
replacement, and it works because the syntax of bash is close enough to /bin/sh.
 NO c-shell-like shell will ever be called in any makefile.  You can use C shell
syntax, if you run C-shell, to set variables, but sh is the environment in which
it will run.  Example: C shells use the "foreach: command, but you will never,
ever get the foreach command to work in any makefile (without some really
special tricks, and there's probably some knonw-it-all who will bring that up if
I don't mention it).  What will work, and what you see quite often in makefiles,
is the "for" command, which is a sh command.

So, summarizing, you use whatever syntax the shell which you run uses, to be
able to set variables, before a make run.  Inside the makefile, you have no
choice, you must use sh syntax.  That means, if you're running bashsh, you could
set LDFLAGS as
export LDFLAGS="whatver you like"
or if you're running tcsh, you could use
setenv LDFLAGS "whatver you like"
and it will work 100% the same inside the makefile.  If your makefile uses
CPLUS_INCLUDE_PATH, then you need either to use CPLUS_INCLUDE_PATH, or edit your
makefile.  Most commonly, what you'll see for that function will be "INCLUDES",
not CPLUS_INCLUDE_PATH, but you never know.  If your makefile uses it' it's by
definition the correct way to go.

It sounds like you hit some author with insufficient experience, or perhaps most
used to using Windows stuff, where they don't even use Makefiles, they use
special purpose project software, and I couldn't be any sort of guide to that, I
don't run Windows.

You might possibly doubt me, so I am not going to push this thread any further,
because I've covered the ground well enough, and maybe others can tell you that
I'm not wrong here (or, perhaps ...)

> 
> ------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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questions-unsubscribe at freebsd.org"
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFH6SWJz62J6PPcoOkRAsBZAJ4uN0WcvGzyR3psrBOsaEI6o9vwVQCfaZB5
Ec6IaYz1lNO6j+uycFRxPEg=
=sFCd
-----END PGP SIGNATURE-----