'import dl' on AMD64 platform

[John Pye]

Hi all

I have a tricky situation that's preventing my Python/SWIG/C
application from running on the Debian Etch AMD64 platform.

It seems that the 'dl' module is not available on that platform. The
only reason I need the 'dl' module, however, is for the values of
RTLD_LAZY etc, which I use with sys.setdlopenflags() in order to make
my imported SWIG module share its symbols correctly with more deeply-
nested plugin modiles in my C-code layer.

I wonder if there is a workaround for this -- perhaps another way to
access the values of those RTLD flags?

Cheers
JP

 

[Nick Craig-Wood]

I have a tricky situation that's preventing my Python/SWIG/C
application from running on the Debian Etch AMD64 platform.

It seems that the 'dl' module is not available on that platform. The
only reason I need the 'dl' module, however, is for the values of
RTLD_LAZY etc, which I use with sys.setdlopenflags() in order to make
my imported SWIG module share its symbols correctly with more deeply-
nested plugin modiles in my C-code layer.

I wonder if there is a workaround for this -- perhaps another way to
access the values of those RTLD flags?

Read stuff out of /usr/include/bits/dlfcn.h ?

It seems to be a constant 1 anyway

#define RTLD_LAZY 0x00001

You could try compiling the dl module by hand.

 

[jim-on-linux]

python help,

I'm testing on xpPro

I have a simple module that sends text files to a
printer. Then, it moves the file to the 'Fprtd'
directory. The module contains the following
code;


#####

for n in PrtList:
os.system('type '+n+ ' > prn'
os.system('move '+n+ ' Fprtd')

#####

os.system opens and closes a window for each file
it sends to the printer and again for each time
it moves a file to the Fprtd directory. If there
were only a few files, this wouldn't be so bad.
But, when the files number 300 to 400 it becomes
objectionable.

Is there any way to supress the flashing window.

xp no longer allows the 'ctty' command.


jim-on-linux

 

[Gabriel Genellina]

I have a simple module that sends text files to a
printer. Then, it moves the file to the 'Fprtd'
directory. The module contains the following
code;


#####

for n in PrtList:
os.system('type '+n+ ' > prn'
os.system('move '+n+ ' Fprtd')

#####

os.system opens and closes a window for each file
it sends to the printer and again for each time
it moves a file to the Fprtd directory. If there
were only a few files, this wouldn't be so bad.
But, when the files number 300 to 400 it becomes
objectionable.

Just code the above in Python itself.
type xxx > prn == copy xxx prn == shutil.copyfile(xxx,prn)
move xxx Fprtd == shutil.move(xxx, Fprtd)

 

[jim-on-linux]

En Sun, 18 Feb 2007 18:09:23 -0300,
jim-on-linux <[email protected]>

escribió:

Thanks Geneilina,
It works fine.
shutil.copyfile(xxx,prn)
jim-on-linux

 

[John Pye]

Read stuff out of /usr/include/bits/dlfcn.h ?

It seems to be a constant 1 anyway

#define RTLD_LAZY 0x00001

You could try compiling the dl module by hand.

Well yes, and that's the workaround I came up with: for systems that
don't provide the 'dl' module, I just default to the values I found on
my linux (ubuntu) system. This is a nasty hack however.

I wonder if anyone could say why the Debian people left out this
important module from their AMD64 platform?

Cheers
JP

 

[Nick Craig-Wood]

Well yes, and that's the workaround I came up with: for systems that
don't provide the 'dl' module, I just default to the values I found on
my linux (ubuntu) system. This is a nasty hack however.

I wonder if anyone could say why the Debian people left out this
important module from their AMD64 platform?

There is a note (from a 2002) in the changelog about

* Always build the dl module. Failure in case of
sizeof(int)!=sizeof(long)!=sizeof(void*)
is delayed until dl.open is called. Closes: #141681.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=141681

so maybe it doesn't build properly on amd64. That, or it violating
the free software guidelines (unlikely in this case) are the two major
reasons for missing features in debian.

The normal procedure would be to try the package from unstable.

If that doesn't work then report a bug. (Easiest with the reportbug
package.)

I don't have an amd64 machine to try otherwise I'd try it for you!

I looked in the latest packages for python2.4 & python2.5 for amd64
and /usr/lib/python2.4/lib-dynload/dl.so doesn't appear to be there.

http://packages.debian.org/cgi-bin/...&version=unstable&arch=amd64&page=9&number=50