dlopen() requires libSDL2.so, not SDL2.so

[GoogleCodeExporter]

Ubuntu 12.10 python 3.2 trunk SDL2

attached patch makes it work for me.

note: I appended same prefix for the darwin platform, can't test it though.

Original issue reported on code.google.com by llxxn...@gmail.com on 17 Nov 2012 at 1:51

Attachments:

• a.patch

[GoogleCodeExporter]

Please verify that the SDL2 library has been correctly picked up by your 
ldconfig caches. The lib prefix should not be necessary within a sane 
Linux/Unix environment with a sane Python 2.x or Python 3.x installation.

I could not reproduce your issue on different Linux (including a Ubuntu 10.x)
and BSD installations, so for now it is assumed to be a local issue in your 
particular
environment.

Original comment by marcusvonappen@googlemail.com on 17 Nov 2012 at 8:18

• Added labels: OpSys-Linux, Python-CPython

[GoogleCodeExporter]

Since there's still no SDL2 release, I install it into a prefix. Even if there 
was one, this use-case is still required for debugging with trunk or variously 
patched SDL.

It of course works if one does an ldconfix /pre/fix . However, I'm not sure 
what would happen if there would be several prefixes plus the system default 
location with a stable release. 

Another separate use-case is the one of distributing SDL2 libs with an app. One 
can't seriously require users to do "sudo ldconfig /path/to/something" when 
this can compromise security of their system. An export LD_LIBRARY_PATH in a 
shell launcher is much more benign.

Original comment by llxxn...@gmail.com on 17 Nov 2012 at 10:02

[GoogleCodeExporter]

No one expects users to perform a ldconfig; using LD_LIBRARY_PATH is something 
the application developer can do and out of the scope of pgreloaded as this 
heavily relies on the distribution and setup mechanism of the particular 
application.

Aside from that you can use pygame2.set_dll_path() to point pygame2 to a 
directory, where the libraries are likely to be found. You can find more 
information about it at 
http://wiki.pgreloaded.googlecode.com/hg/documentation/modules/pygame2.html

Original comment by marcusvonappen@googlemail.com on 17 Nov 2012 at 11:09

• Changed state: WontFix

[GoogleCodeExporter]

Ok. 

What my code does is:

import pygame2, os
pygame2.set_dll_path(os.environ.get('PGLIBDIR', ''))
import pygame2.sdl as sdl

where $PGLIBDIR points to a directory where libSDL2.so and friends are.

This results in:

Traceback (most recent call last):
  File "./py3sdl2.py", line 39, in <module>
    import pygame2.sdl as sdl
  File "/home/lxnt/00DFGL/fgtestbed/lib/python3.2/site-packages/pygame2/sdl/__init__.py", line 17, in <module>
    dll = DLL("SDL 2", ["SDL2", "SDL2-2.0"])
  File "/home/lxnt/00DFGL/fgtestbed/lib/python3.2/site-packages/pygame2/dll/__init__.py", line 55, in __init__
    raise RuntimeError("could not find any library for %s" % libinfo)
RuntimeError: could not find any library for SDL 2

Because:

pygame2.sdl calls DLL("SDL 2", ["SDL2", "SDL2-2.0"])
pygame2.DLL.__init__() calls _findlib(get_dll_path(), ["SDL2", "SDL2-2.0"])
get_dll_path() results in the contents of $PGLIBDIR

pygame2.dll._findlib() does:
  results = []
  for libname in ["SDL2", "SDL2-2.0"]:
    dll = os.path.join($PGLIBDIR, "%s%s" % (libname, ".so"))
    if os.path.exists(dll): - this never happens, since there is no $PGLIBDIR/SDL2.so or SDL2-2.0 file
        results.append(dll) 

  for libname in ["SDL2", "SDL2-2.0"]:
     dll = find_library(libname) - this never finds anything without running ldconfig
     if dll:
       results.append(dll)
  return results  - returns empty list

Then 
if len(foundlibs) == 0:
   raise RuntimeError("could not find any library for %s" % libinfo)

happens.

Summary: pgreloaded requires SDL2 lib directory either be submitted to 
ldconfing, or to contain links to library files without 'lib' prefix. One can 
not rename the library files because of dependencies - i.e. ldd 
libSDL2_image-1.2.so.0 | grep SDL

Why ldconfig requirement is bad we discussed above.

Requiring extra links is bad, because it goes contrary to the established 
convention of library files having 'lib' prefix on platforms in question and 
because it introduces another step a user must take.

My code in question is at https://github.com/lxnt/fgtestbed/ .

My users are those brave folks that agree to test and tinker with it. While it 
is reasonable to expect such a user to be familiar with prefix-installation of 
unreleased code, some yaml and some python, for all of which there is plenty of 
information on the web, I can't expect them to debug issues like the one we are 
discussing.

Thus I respectfully ask my patch to be accepted.

Thank you.

Original comment by llxxn...@gmail.com on 18 Nov 2012 at 10:10

[GoogleCodeExporter]

You are right, I missed the part for providing an own path, since the code then 
relies on the os.path capabilities. Thanks for clarifying!

Your patch has been committed in a slightly modified version in revision 
560f87fe9add (the change to the find_library() call was not taken into account, 
since this should be properly handled by ctypes)

Original comment by marcusvonappen@googlemail.com on 18 Nov 2012 at 3:57

• Changed state: Fixed
• Added labels: OpSys-All, Python-All
• Removed labels: OpSys-Linux, Python-CPython

[GoogleCodeExporter]

thank you.

Original comment by llxxn...@gmail.com on 18 Nov 2012 at 10:25