> > See my followup message. That doesn't take care of shared libraries
> > across multiple platforms, for one. (That's the really major thing that
> > it doesn't take care of, but there are others.)
>
> I would argue that if a shared library has been properly installed, the
> runtime linker
Russ Albery writes:
> Steven G Johnson <[EMAIL PROTECTED]> writes:
> > What's wrong with just doing:
> > ./configure LDFLAGS="-L/usr/local/lib -L/usr/pubsw/lib"
> > CPPFLAGS="-I/usr/local/include -I/usr/pubsw/include"
>
> See my followup message. That doesn't take care of shared libraries
> acro
Steven G Johnson <[EMAIL PROTECTED]> writes:
> What's wrong with just doing:
> ./configure LDFLAGS="-L/usr/local/lib -L/usr/pubsw/lib"
> CPPFLAGS="-I/usr/local/include -I/usr/pubsw/include"
See my followup message. That doesn't take care of shared libraries
across multiple platforms, for one.
Russ Allbery writes:
> What I'd love to see is a way to pass the configure script a whole
> list of directories into which software may be installed, not just
> /usr/local and /usr/pubsw but also /usr/pubsw/apps/db3 and
> /usr/pubsw/apps/openssl and other directories that have a lib and
> include
Russ Allbery writes:
> What I'd love to see is a way to pass the configure script a whole list of
> directories into which software may be installed, not just /usr/local and
> /usr/pubsw but also /usr/pubsw/apps/db3 and /usr/pubsw/apps/openssl and
> other directories that have a lib and include s
Mike Castle <[EMAIL PROTECTED]> writes:
> On Tue, May 22, 2001 at 03:37:37PM -0700, Russ Allbery wrote:
>> Widespread support for such a feature in configure scripts would make
>> my life *significantly* easier. Currently I actually hack gcc to look
>> in both /usr/local and /usr/pubsw, and I'd
On Tue, May 22, 2001 at 03:37:37PM -0700, Russ Allbery wrote:
> Widespread support for such a feature in configure scripts would make my
> life *significantly* easier. Currently I actually hack gcc to look in
> both /usr/local and /usr/pubsw, and I'd love to get rid of that hack but
> it makes bu
Steve M Robbins <[EMAIL PROTECTED]> writes:
> Recently, I've begun adding a simple "--with-build-path" option to my
> configure scripts, to allow specifying a colon-separated list of
> locations to search for libraries. If you say --with-build-path=/a:/b,
> then /a/include and /b/include are add
On Mon, May 21, 2001 at 06:50:57PM -0700, Russ Allbery wrote:
> Bruno Haible <[EMAIL PROTECTED]> writes:
>
> > I would like to propose a "configure" option --use-local which,
> > depending on the language being used, does the following. For C and C++,
> > it appends " -I/usr/local/include" to CPP
Bruno Haible <[EMAIL PROTECTED]> writes:
> I would like to propose a "configure" option --use-local which,
> depending on the language being used, does the following. For C and C++,
> it appends " -I/usr/local/include" to CPPFLAGS and " -L/usr/local/lib"
> to LDFLAGS. For Fortran, it should do si
On Mon, 21 May 2001, Bruno Haible wrote:
> So, in fact, it is a problem with *most* platforms, excluding GNU.
> This is also what is written in the GNU standards:
>
> Most compilers other than GCC do not look for header files in
> directory `/usr/local/include'. So installing the heade
Bruno Haible wrote:
> [...]
> Another totally different approach is to recommend that every
> library libfoo comes with a script 'foo-config' in /usr/local/bin that
> can spit out the required -I and -L options. Here as well, autoconf
> support would be nice, so that the resulting -I/-L options w
Hi,
You remember the need for
CPPFLAGS=-I/usr/local/include LDFLAGS=-L/usr/local/lib
while running configure? (We discussed this around 2001-03-15, subject
"installation instructions on OpenBSD and FreeBSD".)
It is not only a problem with *BSD. Also all of
SunOS 4cc
Solariscc
A
13 matches
Mail list logo
