[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

gcc in Sarge - searching in /usr/local/include & what related libs!?



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>----------

zito@bobek tmp $ gcc -Wall -o 1 1.c -lcrypto -lssl && ./1 
inc: 90707f   lib: 90705f
bad :-(
zito@bobek 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
zito@bobek tmp $

Headers under /usr/local takes precedence over /usr/include (headers
from libssl-dev). Ok, but library was taken from /usr/lib!

zito@bobek 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.

zito@bobek tmp $ gcc -Wall  -o 1 1.c -L/usr/local/lib  -lssl -lcrypto \
&& ./1 
inc: 90707f   lib: 90705f
bad :-(

Fiddling with -L dtto.

zito@bobek 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



Reply to: