headers
Michael Snyder | 2 Mar 2010 01:37
Favicon

python config question

Question about --with-python=$PATH.

If I have python version X installed "natively" on my build machine
(eg. at /usr/lib/libpython.*), and version Y installed somewhere else
(eg. at $PYPATH), and I tell configure that I want to use the one at
$PYPATH, eg.

     configure --with-python=$PYPATH

Shouldn't I expect gdb to be linked against python version Y?

That doesn't seem to be what happens, in fact "ldd" tells me
that gdb wants to use version X at /usr/lib/libpython*.
Permalink | Reply | 8 comments |
headers
Joel Brobecker | 2 Mar 2010 06:22
Favicon

Re: python config question

>     configure --with-python=$PYPATH
> 
> Shouldn't I expect gdb to be linked against python version Y?

I would think so. But from what I can tell by looking at the configury,
I think that your GDB was in fact linked against the Python install
that you provided (using -L${with_python}/lib in the link command).
However, your loader is selecting the libpython in your default install
because it does not know about you local one. You have several solutions
to fix this, typical ones being: use th rpath during the link, or
add your python install lib dir to LD_LIBRARY_PATH, for instance.

--

-- 
Joel
Permalink | Reply | 7 comments |
headers
Michael Snyder | 2 Mar 2010 19:11
Favicon

Re: python config question

Joel Brobecker wrote:
>>     configure --with-python=$PYPATH
>>
>> Shouldn't I expect gdb to be linked against python version Y?
> 
> I would think so. But from what I can tell by looking at the configury,
> I think that your GDB was in fact linked against the Python install
> that you provided (using -L${with_python}/lib in the link command).
> However, your loader is selecting the libpython in your default install
> because it does not know about you local one. You have several solutions
> to fix this, typical ones being: use th rpath during the link, or
> add your python install lib dir to LD_LIBRARY_PATH, for instance.
> 

Maybe the configure option should include rpath?
Permalink | Reply | 6 comments |
headers
Brian Budge | 2 Mar 2010 22:17
Picon

cannot step into class member function in dlopen'ed library

Hi all -

I'm having trouble stepping into a class member function in a
dlopen'ed library.  I've ensured that the library is built and linked
by g++ with the -g option.  When I couldn't step in, I tried putting a
breakpoint in the source of the library by line number.  gdb does
break there, but complains that there are no line numbers available.

Strangely, it seems that I've been able to step in before, but now I
can't.  Has anyone encountered this, and if so, is there a good
solution?

Thanks,
  Brian
Permalink | Reply | 1 comment |
headers
Joel Brobecker | 3 Mar 2010 05:50
Favicon

Re: python config question

> Maybe the configure option should include rpath?

It could.  We're touching at something that is very platform-dependent,
though - perhaps you want to look at using libtool (although I'll admit
to a severe aversion to this tool, probably unjustified). If I were in
your position, I might consider linking statically against libpython.
At AdaCore, the plan is to use LD_LIBRARY_PATH, which we'll have to do,
since customers are free to install the binary package wherever they
want (hence preventing rpath from working).

--

-- 
Joel
Permalink | Reply | 5 comments |
headers
Jan Kratochvil | 3 Mar 2010 10:20
Picon
Favicon

Re: python config question

On Wed, 03 Mar 2010 05:50:39 +0100, Joel Brobecker wrote:
> > Maybe the configure option should include rpath?
> 
> It could.  We're touching at something that is very platform-dependent,
> though - perhaps you want to look at using libtool (although I'll admit
> to a severe aversion to this tool, probably unjustified). If I were in
> your position, I might consider linking statically against libpython.
> At AdaCore, the plan is to use LD_LIBRARY_PATH, which we'll have to do,
> since customers are free to install the binary package wherever they
> want (hence preventing rpath from working).

IIUC you ship libpython*.so.* libraries bundled with the shipped gdb.
Isn't ld.so's $ORIGIN useful?

$ORIGIN and rpath
	ld.so understands the string $ORIGIN (or equivalently ${ORIGIN}) in an
	rpath specification (DT_RPATH or DT_RUNPATH) to mean the directory
	containing the application executable.  Thus, an application located
	in somedir/app could be compiled with gcc -Wl,-rpath,'$ORIGIN/../lib'
	so that it finds an associated shared library in somedir/lib no matter
	where somedir is located in the directory hierarchy.  This facilitates
	the creation of "turn-key" applications that do not need to be
	installed into special directories, but can instead be unpacked into
	any directory and still find their own shared libraries.

Regards,
Jan
Permalink | Reply | 4 comments |
headers
Joel Brobecker | 3 Mar 2010 10:45
Favicon

Re: python config question

> IIUC you ship libpython*.so.* libraries bundled with the shipped gdb.
> Isn't ld.so's $ORIGIN useful?

Yep - very useful (in fact, I had forgotten about this already).
I just wanted to give Michael some of the standard options to deal
with his situation...

--

-- 
Joel
Permalink | Reply | 0 comments |
headers
Anton Kunze | 3 Mar 2010 12:37
Picon
Favicon

configure: error: no usable python found

Hello,

I try to compile gdb 7.0.1 with python on suse linux, but I get this
error message ("no usable python found").

1. I build python in folder "/usr/lib/Python-2.6.4" with "./configure --enable-shared" and "make"
2. I compile gdb with "./configure --with-python=/usr/lib/Python-2.6.4" and "make"
3. I get this message on the end:

checking whether to use python... /usr/lib/Python-2.6.4
checking for python2.6... no
checking for python2.5... no
checking for python2.4... no
configure: error: no usable python found at /usr/lib/Python-2.6.4

Files on /usr/lib/Python-2.6.4:
drwxr-xr-x 5 root root 4096 1. Mär 18:22 build
-rw-r--r-- 1 root root 329565 2. Mär 10:54 config.log
-rwxr-xr-x 1 root root 44843 2. Mär 10:54 config.status
-rwxr-xr-x 1 root root 684664 29. Sep 15:01 configure
-rw-r--r-- 1 root root 109668 29. Sep 15:01 configure.in
drwxr-xr-x 23 root root 4096 26. Okt 02:49 Demo
drwxr-xr-x 16 root root 4096 26. Okt 02:56 Doc
drwxr-xr-x 2 root root 4096 26. Okt 02:49 Grammar
drwxr-xr-x 2 root root 4096 26. Okt 02:49 Include
-rwxr-xr-x 1 root root 7122 14. Jun 2003 install-sh
drwxr-xr-x 44 root root 12288 2. Mär 10:55 Lib
lrwxrwxrwx 1 root root 36 2. Mär 09:31 libpython2.6 ->
/usr/lib/Python-2.6.4/libpython2.6.a
-rw-r--r-- 1 root root 5803312 2. Mär 10:55 libpython2.6.a
(Continue reading)

Permalink | Reply | 11 comments |
headers
Joel Brobecker | 3 Mar 2010 12:54
Favicon

Re: configure: error: no usable python found

> checking whether to use python... /usr/lib/Python-2.6.4
> checking for python2.6... no
> checking for python2.5... no
> checking for python2.4... no
> configure: error: no usable python found at /usr/lib/Python-2.6.4

I'd recommend that you check the gdb/config.log file.  Somewhere
close to the end, before configure dumped its entire environment,
you should see the compile check that was used to check for python2.6,
and the error that caused configure discard to 2.6 python install.

--

-- 
Joel
Permalink | Reply | 8 comments |
headers
Andreas Schwab | 3 Mar 2010 13:11
Picon
Favicon

Re: configure: error: no usable python found

Anton Kunze <ak <at> technosis.de> writes:

> 1. I build python in folder "/usr/lib/Python-2.6.4" with "./configure --enable-shared" and "make"

You run make install then.

Andreas.

--

-- 
Andreas Schwab, schwab <at> redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."
Permalink | Reply | 1 comment |

Gmane