Q: (or bug?) LD_LIBRARY_PATH and CPLUS_INCLUDE_PATH handling in egcs-1.1.1

[Eric Maryniak <e dot maryniak at pobox dot com>]

Dear netters,

Excuse me for possibly asking something stupid or something that's been
discussed before, but i'm very new to this list. I'm also not an expert
on gcc/egcs---i just "./configure && make && make install" and use it ;-)

Recently, when i compiled Postfix (Wietse's sendmail replacement, see
http://www.postfix.org/) and MySQL (http://www.mysql.com/) under Solaris 2.5.1
with egcs-1.1.1, I encountered problems with LD_LIBRARY_PATH (Postfix' makefile
explicitly requires _unsetting_ it!) and CPLUS_INCLUDE_PATH
MySQL did not compile if /usr/include is in front in CPLUS_INCLUDE_PATH.
(note: if you previously used Sun's cc, eg. to bootstrap gcc ;-), you'll
 probably have set this variable, maybe even system-wide)
The probable cause was that in /usr/include/stdarg.h  __builtin_va_alist
was undefined---somehow the egcs does not use it's own stdarg.h (which is
very different from Sun's!), although gcc -v says:

Reading specs from
    /usr/local/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.91.60/specs
  gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release)

I would assume gcc would know where to find it's own .h files, namely
"/usr/local/lib/gcc-lib/sparc-sun-solaris2.5.1/egcs-2.91.60/include/stdarg.h"
and give proper precedence... Inspection of the egcs 1.1.1 source,
   egrep '(LD_LIBRARY_PATH|CPLUS_INCLUDE_PATH)' `find . -type f -print`
learned that even in egcs 1.1.1 different modules seem to do different
things with these envirs. (ie. sometimes GET_ENVIRONMENT and sometimes
a hard "p=getenv"):

./etc/ChangeLog:        * comp-tools-fix: set LD_LIBRARY_PATH
./Makefile.in:RPATH_ENVVAR = LD_LIBRARY_PATH
./configure.in:# If --enable-shared was set, we must set LD_LIBRARY_PATH so that
 the
./ltconfig:  shlibpath_var=LD_LIBRARY_PATH
...
./ltmain.sh:      # LD_LIBRARY_PATH before the program is installed.
./gcc/ChangeLog.10:     * collect2.c (locatelib): Fix parsing of LD_LIBRARY_PATH
.
./gcc/cccp.c:   GET_ENVIRONMENT (epath, "CPLUS_INCLUDE_PATH");
./gcc/collect2.c:      p = getenv ("LD_LIBRARY_PATH");
./gcc/cpplib.c: GET_ENVIRONMENT (epath, "CPLUS_INCLUDE_PATH");
./gcc/invoke.texi:@itemx CPLUS_INCLUDE_PATH
./gcc/invoke.texi:@findex CPLUS_INCLUDE_PATH
./libio/ChangeLog:      * config.shared (check): Set LD_LIBRARY_PATH.
./libio/ChangeLog:      LD_LIBRARY_PATH themselves.
./libio/ChangeLog:      LD_LIBRARY_PATH and .EXPORT_ALL_VARIABLES:.
./libio/config.shared:    echo >&2 '    SAVE_LLPATH="$${SAVE_LLPATH-$$LD_LIBRARY
_PATH}"; export SAVE_LLPATH; \'
./libio/config.shared:    echo >&2 '    LD_LIBRARY_PATH="$${rootme}${TOLIBGXX}..
/libstdc++:$${rootme}${TOLIBGXX}../libg++:$$SAVE_LLPATH"; \'
./libio/config.shared:    echo >&2 '    export LD_LIBRARY_PATH; \'
./libstdc++/ChangeLog:  no longer needed now that make check sets LD_LIBRARY_PAT
H.
./libstdc++/tests/ChangeLog:    * Makefile.in: Don't set LD_LIBRARY_PATH.  Users
 will have to set
./libstdc++/testsuite/ChangeLog:        * lib/libstdc++.exp (test_libstdc++): Se
t LD_LIBRARY_PATH

Moreover, I could not find them documented in the gcc man page!
Only invoke.texi mentions the behaviour:
---
These environment variables pertain to particular languages.  Each
variable's value is a colon-separated list of directories, much like
@code{PATH}.  When GNU CC searches for header files, it tries the
directories listed in the variable for the language you are using, after
the directories specified with @samp{-I} but before the standard header
file directories.
---
So my questions are: is that behaviour desirable? shouldn't configure or gcc
  warn if there are multiple conflicting include files, especially standard
  (but obsolete) include files overriding gcc's own? shouldn't the envirs be
  described in the gcc and g++ man page?

Eric.
--
Eric Maryniak <e.maryniak@pobox.com>
Home page: http://pobox.com/~e.maryniak/
Netherlands Institute for Scientific Information Services (NIWI)
Tel/Fax: +31 20 4628650/6685079. Internet: http://www.niwi.knaw.nl/

I don't have a solution, but I most definitely admire the problem.