On Jan 27, 6:00 pm, "Drew Smathers" <[EMAIL PROTECTED]> wrote:
> On Jan 27, 2008 6:32 PM, Gary <[EMAIL PROTECTED]> wrote:
>
>
>
> > Not true. Keyword parameters of the form platform=path are only
> > applied when on the specified platform, so the linux2= will not
> > affect
> > execution of load_library on MacOSX in any way. (Just like the
> > darwin=
> > parameter is completely ignored on Window's and Linux.)
>
> Hmmm ... no, it is true. You're suggesting a fix that changes the darwin
> keyword to darwin='/lib/libc.so.6' - so this *would* break on MacOSX -
> that's my point. I know that the linux2 keyword arg is ignored on other
> platforms ...
Ahhh, I finally see where the misunderstanding is... I merely
intended to add the linux2 keyword. I did not (intentionally) change
the darwin keyword's value, nor is it changed in my own code. Some
cut and past error I guess. Sorry for the misunderstanding.
On a separate note, and the probable cause of the extra cutting and
pasting error, I can't seem to post to this group via email -- I must
use the web interface. Is this necessary? I do find the web
interface much more clumsy than my usual email client.
Gary Herron
>
>
>
> > Again, not quite right. I did mis-label the branch when I said it was
> > MacOSX. In fact there are two branches to the if -- one for win32 and
> > cygwin, and the other for everything else, including Linux and
> > MacOSX.
> > And in fact, ctypes is *not* following the ld linker script in
> > /usr/lib/libc.so, but instead gives an error claiming that the file
> > does
> > not have an ELF header. (Which is true -- since the file is ascii
> > text.) Perhaps ctypes should handle such a file, but it is not in
> > this
> > case. Maybe this is a ctypes bug.
>
> Yes, I incorrectly commented on this. ctypes does *not* handle ld linker
> scripts. My guess is that when the linux loader in pyglet.lib builds the
> cache based on libs it finds in /lib and /usr/lib, it hashes to
> /usr/lib/libc.so - and this causes the 'splosion.
>
> Try any experiment on your system using ctypes to see if it will find libc
> with:
>
> >>> import ctypes.utils
> >>> ctypes.utils.find_library('c')
Nope. That works fine (but its 'util', not 'utils')
>>> import ctypes.util
>>> ctypes.util.find_library('c')
'libc.so.6'
>
> This probably returns None on your box suggesting your gcc setup might be
> wrong for whatever reason.
It's hard to believe I could compile the *whole* linux system and
applications with in incorrect gcc setup. But it's hard to argue that
it's right when it fails in pyglet.
> On my gentoo box it works fine. I would start
> nagging the ctypes guys to add support for ld linker scripts which would
> solve this problem eventually. I can't think of how pyglet.lib could be
> patched to handle this case without making the so cache generation really
> slow - like looking inside linker scripts to resolve the canonical path to
> the so.
>
> --
> Drew
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"pyglet-users" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/pyglet-users?hl=en
-~----------~----~----~----~------~----~------~--~---
