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]