--- Begin Message ---
- To: submit@bugs.debian.org
- Subject: gcc - inconsistent searching in /usr/local for incs & libs
- From: Václav Ovsík <vaclav.ovsik@i.cz>
- Date: Mon, 11 Jul 2005 16:56:04 +0200
- Message-id: <20050711145603.GD21356@bobek.pm.i.cz>
Package: gcc-3.3
Version: 3.3.5-13
I'm simply forwarding message I sent to debian-gcc@lists.debian.org
without any reaction. This bug was not in Woody. I found it after
upgrade to Sarge. In short: when the same header(s) & lib(s) (different
in version) are installed into /usr/local as they are in the system
(openssl libs in mail bellow), then searching order is some for incs and
other for libs. This causes /usr/local unusable in this situation.
Please, see details below.
----- Forwarded message from Václav Ovsík <vaclav.ovsik@i.cz> -----
From: Václav Ovsík <vaclav.ovsik@i.cz>
Subject: gcc in Sarge - searching in /usr/local/include & what related libs!?
To: Debian GCC maintainers <debian-gcc@lists.debian.org>
Date: Wed, 15 Jun 2005 17:18:00 +0200
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
----- End forwarded message -----
Regards
--
Vaclav Ovsik
--- End Message ---