* [gentoo-embedded] linking against gdbm fails when emerging python
@ 2005-09-22 9:33 99% Natanael Copa
0 siblings, 0 replies; 1+ results
From: Natanael Copa @ 2005-09-22 9:33 UTC (permalink / raw
To: gentoo-embedded
I am trying to upgrade to python 2.3.5-r2 but I get this error:
i386-gentoo-linux-uclibc-gcc -pthread -DNDEBUG -march=i386 -Os -pipe
-fomit-frame-pointer -fPIC -fno-strict-aliasing -DHAVE_GDBM_NDBM_H -I.
-I/var/tmp/portage/python-2.3.5-r2/work/Python-2.3.5/./Include
-I/var/tmp/portage/python-2.3.5-r2/work/Python-2.3.5/Include
-I/var/tmp/portage/python-2.3.5-r2/work/Python-2.3.5 -c
/var/tmp/portage/python-2.3.5-r2/work/Python-2.3.5/Modules/dbmmodule.c
-o build/temp.linux-i686-2.3/dbmmodule.o
i386-gentoo-linux-uclibc-gcc -pthread -shared
build/temp.linux-i686-2.3/dbmmodule.o -L/usr/local/lib -lgdbm -o
build/lib.linux-i686-2.3/dbm.so
./python: can't resolve symbol 'dbm_firstkey'
make: *** [sharedmods] Error 1
I dont have gdbm in the useflags.
I tried to reemerge gdbm, same thing happens.
I tried to enable gdbm in the useflags but same thing happens.
So I tried to re-emerge the current python with emerge
=dev-lang/python-2.3.5 but the same thing happens.
So I suspect that my build environment is broken somwhere somehow.
Maybe I used to have gdbm in the useflags but it have been removed?
Anyone experienced the same thing?
Shouldn't there be a -L/usr/lib instead of -L/usr/local/lib?
Does anyone have a suggestion how to bypass?
-- Natanael Copa
--
gentoo-embedded@gentoo.org mailing list
^ permalink raw reply [relevance 99%]
Results 1-1 of 1 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2005-09-22 9:33 99% [gentoo-embedded] linking against gdbm fails when emerging python Natanael Copa
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox