Hello,
I have a question about gcc behavior when searching includes & libs on
Debian Sarge. Is it really needed to search for anything in /usr/local
by default? I think, autoconf generated flags for gcc can handle
searching in /usr/local on his own (Or not?)
I am afraid, that behavior of gcc 3.3.5-13 is broken now.
Example:
I have installed package libssl0.9.7 (0.9.7e-3), but I want to have
newver version in /usr/local (openssl-0.9.7g or some current snapshot)
via GNU Stow organiser. I had also installed package libssl-dev,
but it's removing solved nothing.
Consider following code (file 1.c):
----------<snip>----------
#include <stdio.h>
#include <openssl/opensslv.h>
#include <openssl/crypto.h>
int main(void)
{
printf("inc: %lx lib: %lx\n", OPENSSL_VERSION_NUMBER, SSLeay());
if ( SSLeay() == OPENSSL_VERSION_NUMBER )
{
printf("ok :-)\n");
return 0;
}
else
{
printf("bad :-(\n");
return 1;
}
}
----------<snip>----------
[EMAIL PROTECTED] tmp $ gcc -Wall -o 1 1.c -lcrypto -lssl && ./1
inc: 90707f lib: 90705f
bad :-(
[EMAIL PROTECTED] tmp $ gcc -M 1.c
1.o: 1.c /usr/include/stdio.h /usr/include/features.h \
/usr/include/sys/cdefs.h /usr/include/gnu/stubs.h \
/usr/lib/gcc-lib/i486-linux/3.3.5/include/stddef.h \
/usr/include/bits/types.h /usr/include/bits/wordsize.h \
/usr/include/bits/typesizes.h /usr/include/libio.h \
/usr/include/_G_config.h /usr/include/wchar.h /usr/include/bits/wchar.h \
/usr/include/gconv.h /usr/lib/gcc-lib/i486-linux/3.3.5/include/stdarg.h \
/usr/include/bits/stdio_lim.h /usr/include/bits/sys_errlist.h \
/usr/local/include/openssl/opensslv.h \
/usr/local/include/openssl/crypto.h /usr/include/stdlib.h \
/usr/include/sys/types.h /usr/include/time.h /usr/include/endian.h \
/usr/include/bits/endian.h /usr/include/sys/select.h \
/usr/include/bits/select.h /usr/include/bits/sigset.h \
/usr/include/bits/time.h /usr/include/sys/sysmacros.h \
/usr/include/bits/pthreadtypes.h /usr/include/bits/sched.h \
/usr/include/alloca.h /usr/local/include/openssl/stack.h \
/usr/local/include/openssl/safestack.h \
/usr/local/include/openssl/symhacks.h \
/usr/local/include/openssl/e_os2.h \
/usr/local/include/openssl/opensslconf.h
[EMAIL PROTECTED] tmp $
Headers under /usr/local takes precedence over /usr/include (headers
from libssl-dev). Ok, but library was taken from /usr/lib!
[EMAIL PROTECTED] tmp $ gcc -Wall -I/usr/include -o 1 1.c -lssl -lcrypto && ./1
inc: 90707f lib: 90705f
bad :-(
Fiddling with -I has no effect on system directories of course.
[EMAIL PROTECTED] tmp $ gcc -Wall -o 1 1.c -L/usr/local/lib -lssl -lcrypto \
&& ./1
inc: 90707f lib: 90705f
bad :-(
Fiddling with -L dtto.
[EMAIL PROTECTED] tmp $ gcc -static -Wall -o 1 1.c -L/usr/local/lib -lssl \
-lcrypto && ./1
inc: 90707f lib: 90707f
ok :-)
I have static libs under /usr/local, so this happened ok :-).
I tried to use gcc 4 on Woody (myself compiled into /usr/local) and
discover after severel build/install cycles, that only reasonable way
of using "local-prefix" feature of gcc is to set it to some non existent
directory :-).
../gcc-4.0.0/configure \
--program-suffix=-4.0 \
--disable-nls \
--enable-languges=c,c++,java \
--with-local-prefix=/usr/local2 \
--with-gnu-as --with-as=/usr/local/bin/as-2.16 \
--with-gnu-ld --with-ld=/usr/local/bin/ld-2.16
With non existent /usr/local2 I was happy.
Gcc configured this way I can direct using -I & -L to use what I needed.
export CPPFLAGS=-I/usr/local/include
export LDFLAGS=-L/usr/local/lib
When --with-local-prefix with value of some directory is used,
then search order is fixed in gcc :-(.
Not using of local prefix is more flexible IMHO.
Excuse my English please.
Best Regards
--
Vaclav Ovsik
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
