Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss
Next release
17 views
Skip to first unread message
Kartik Thakore
Aug 23, 2012, 8:49:40 PM8/23/12
to Tobias Leich, sdl-...@perl.org, Jeffrey Palmer
Hey guys,
It looks like SDL lastest experimental has quite a few bit of fails. May I
get a summary of what the fails are?
Regards
It looks like SDL lastest experimental has quite a few bit of fails. May I
get a summary of what the fails are?
Regards
Jeffrey Palmer
Aug 23, 2012, 9:40:36 PM8/23/12
to Kartik Thakore, Tobias Leich, sdl-...@perl.org
Hi,
I think the problem is TIFF support on BSD and Solaris, but FROGGS will
know for sure.
Jeff
I think the problem is TIFF support on BSD and Solaris, but FROGGS will
know for sure.
Jeff
Kartik Thakore
Aug 23, 2012, 9:40:55 PM8/23/12
to Jeffrey Palmer, Tobias Leich, sdl-...@perl.org
Awesome thanks.
Kartik Thakore
On 2012-08-23, at 9:40 PM, Jeffrey Palmer <jeffrey....@gmail.com>
wrote:
Kartik Thakore
On 2012-08-23, at 9:40 PM, Jeffrey Palmer <jeffrey....@gmail.com>
wrote:
em...@froggs.de
Aug 24, 2012, 4:11:41 AM8/24/12
to Kartik Thakore, Jeffrey Palmer, sdl-...@perl.org
Hi pals!
In the last time we did, in my opinion, a big mistake. In test scripts
we checked for libpng like: SDL::Config->has('png'). But this didnt
ever returned true, Simply because the HAVE_PNG was only set when
actually building that lib in SDL. (Note: not Alien::SDL)
This ->has() method works pretty fine for stuff like SDL_gfx, since it
will return true if we found SDL_gfx*.h. But there was no check for
png.h at this stage. So even if we found libpng in system dirs or when
we build it on our own, ->has('png') never returned true.
I changed the tests so it checks now for libpng in the shlib-hash that
we get from Alien::SDL. This hash contains all found/build libs, and
their path.
And why does it fail then?
BSD. LibPNG needs libz to run. Normally you would think that libpng is
actually linked against libz, but hey, the BSD ppl dont think that
way. I dont know the reasons but they decided to somehow build libpng
without linking against libz.
when you do: ldd /path/to/libpng.so you will get all the dependencies
printed as a list. This works pretty fine on most systems, like on our
ubuntu's and what not.
On OpemBSD it prints an error message that the lib cant be loaded. But
if you do LD_PRELOAD_LIBS=/path/to/libz.so ldd /path/to/libpng.so it
will work. So we have to preload the lib in order libpng will use it.
Doing this needs to happen on a very early level. Doing it from within
a running perl is to late, even if we load libpng using DynaLoader.
The only thing I can think about atm is that we run a perl, load that
libz.so, and start a child perl process that does the stuff we do now.
This problem applies to libpng (needs libz), libtiff (needs libjpeg)
and libvorbis (needs libogg).
Before YAPC::EU I was working hard on that thing, I guess I can supply
a patch in a few days.
Another problem that exists right now is that the old G4-Macs dont
have a header file we want to use, I will debug that at some point. I
dont think that there are so many users with a G4. These fails only
come from BinGOs so far.
And there are still SDL::Controller(::Interface) fails. But since I
dont really understand whats happening there it would be cool if the
author (you kathekore ;o) would have a look at it.
So far from me, I will write a msg about the YAPC later.
See ya and take care,
Tobias
Zitat von Kartik Thakore <thakore...@gmail.com>:
In the last time we did, in my opinion, a big mistake. In test scripts
we checked for libpng like: SDL::Config->has('png'). But this didnt
ever returned true, Simply because the HAVE_PNG was only set when
actually building that lib in SDL. (Note: not Alien::SDL)
This ->has() method works pretty fine for stuff like SDL_gfx, since it
will return true if we found SDL_gfx*.h. But there was no check for
png.h at this stage. So even if we found libpng in system dirs or when
we build it on our own, ->has('png') never returned true.
I changed the tests so it checks now for libpng in the shlib-hash that
we get from Alien::SDL. This hash contains all found/build libs, and
their path.
And why does it fail then?
BSD. LibPNG needs libz to run. Normally you would think that libpng is
actually linked against libz, but hey, the BSD ppl dont think that
way. I dont know the reasons but they decided to somehow build libpng
without linking against libz.
when you do: ldd /path/to/libpng.so you will get all the dependencies
printed as a list. This works pretty fine on most systems, like on our
ubuntu's and what not.
On OpemBSD it prints an error message that the lib cant be loaded. But
if you do LD_PRELOAD_LIBS=/path/to/libz.so ldd /path/to/libpng.so it
will work. So we have to preload the lib in order libpng will use it.
Doing this needs to happen on a very early level. Doing it from within
a running perl is to late, even if we load libpng using DynaLoader.
The only thing I can think about atm is that we run a perl, load that
libz.so, and start a child perl process that does the stuff we do now.
This problem applies to libpng (needs libz), libtiff (needs libjpeg)
and libvorbis (needs libogg).
Before YAPC::EU I was working hard on that thing, I guess I can supply
a patch in a few days.
Another problem that exists right now is that the old G4-Macs dont
have a header file we want to use, I will debug that at some point. I
dont think that there are so many users with a G4. These fails only
come from BinGOs so far.
And there are still SDL::Controller(::Interface) fails. But since I
dont really understand whats happening there it would be cool if the
author (you kathekore ;o) would have a look at it.
So far from me, I will write a msg about the YAPC later.
See ya and take care,
Tobias
Zitat von Kartik Thakore <thakore...@gmail.com>:
Kartik Thakore
Aug 24, 2012, 12:21:11 PM8/24/12
to em...@froggs.de, sdl-...@perl.org
Ok i will twiddle with it. Do you have a freebsd machine I can ssh too? Or
a vmware image?
>> >**wrote:
a vmware image?
On Aug 24, 2012 4:11 AM, <em...@froggs.de> wrote:
> Hi pals!
>
> In the last time we did, in my opinion, a big mistake. In test scripts we
> checked for libpng like: SDL::Config->has('png'). But this didnt ever
> returned true, Simply because the HAVE_PNG was only set when actually
> building that lib in SDL. (Note: not Alien::SDL)
> This ->has() method works pretty fine for stuff like SDL_gfx, since it
> will return true if we found SDL_gfx*.h. But there was no check for png.h
> at this stage. So even if we found libpng in system dirs or when we build
> it on our own, ->has('png') never returned true.
>
> I changed the tests so it checks now for libpng in the shlib-hash that we
> get from Alien::SDL. This hash contains all found/build libs, and their
> path.
>
> And why does it fail then?
> BSD. LibPNG needs libz to run. Normally you would think that libpng is
> actually linked against libz, but hey, the BSD ppl dont think that way. I
> dont know the reasons but they decided to somehow build libpng without
> linking against libz.
> when you do: ldd /path/to/libpng.so you will get all the dependencies
> printed as a list. This works pretty fine on most systems, like on our
> ubuntu's and what not.
> On OpemBSD it prints an error message that the lib cant be loaded. But if
> you do LD_PRELOAD_LIBS=/path/to/libz.**so ldd /path/to/libpng.so it will
> Hi pals!
>
> In the last time we did, in my opinion, a big mistake. In test scripts we
> checked for libpng like: SDL::Config->has('png'). But this didnt ever
> returned true, Simply because the HAVE_PNG was only set when actually
> building that lib in SDL. (Note: not Alien::SDL)
> This ->has() method works pretty fine for stuff like SDL_gfx, since it
> will return true if we found SDL_gfx*.h. But there was no check for png.h
> at this stage. So even if we found libpng in system dirs or when we build
> it on our own, ->has('png') never returned true.
>
> I changed the tests so it checks now for libpng in the shlib-hash that we
> get from Alien::SDL. This hash contains all found/build libs, and their
> path.
>
> And why does it fail then?
> BSD. LibPNG needs libz to run. Normally you would think that libpng is
> actually linked against libz, but hey, the BSD ppl dont think that way. I
> dont know the reasons but they decided to somehow build libpng without
> linking against libz.
> when you do: ldd /path/to/libpng.so you will get all the dependencies
> printed as a list. This works pretty fine on most systems, like on our
> ubuntu's and what not.
> On OpemBSD it prints an error message that the lib cant be loaded. But if
Kartik Thakore
Aug 24, 2012, 12:22:05 PM8/24/12
to em...@froggs.de, sdl-...@perl.org, Jeffrey Palmer
I can bug bingos for access to his g4 too
>> >**wrote:
> Hi pals!
>
> In the last time we did, in my opinion, a big mistake. In test scripts we
> checked for libpng like: SDL::Config->has('png'). But this didnt ever
> returned true, Simply because the HAVE_PNG was only set when actually
> building that lib in SDL. (Note: not Alien::SDL)
> This ->has() method works pretty fine for stuff like SDL_gfx, since it
> will return true if we found SDL_gfx*.h. But there was no check for png.h
> at this stage. So even if we found libpng in system dirs or when we build
> it on our own, ->has('png') never returned true.
>
> I changed the tests so it checks now for libpng in the shlib-hash that we
> get from Alien::SDL. This hash contains all found/build libs, and their
> path.
>
> And why does it fail then?
> BSD. LibPNG needs libz to run. Normally you would think that libpng is
> actually linked against libz, but hey, the BSD ppl dont think that way. I
> dont know the reasons but they decided to somehow build libpng without
> linking against libz.
> when you do: ldd /path/to/libpng.so you will get all the dependencies
> printed as a list. This works pretty fine on most systems, like on our
> ubuntu's and what not.
> On OpemBSD it prints an error message that the lib cant be loaded. But if
> you do LD_PRELOAD_LIBS=/path/to/libz.**so ldd /path/to/libpng.so it will
>
> In the last time we did, in my opinion, a big mistake. In test scripts we
> checked for libpng like: SDL::Config->has('png'). But this didnt ever
> returned true, Simply because the HAVE_PNG was only set when actually
> building that lib in SDL. (Note: not Alien::SDL)
> This ->has() method works pretty fine for stuff like SDL_gfx, since it
> will return true if we found SDL_gfx*.h. But there was no check for png.h
> at this stage. So even if we found libpng in system dirs or when we build
> it on our own, ->has('png') never returned true.
>
> I changed the tests so it checks now for libpng in the shlib-hash that we
> get from Alien::SDL. This hash contains all found/build libs, and their
> path.
>
> And why does it fail then?
> BSD. LibPNG needs libz to run. Normally you would think that libpng is
> actually linked against libz, but hey, the BSD ppl dont think that way. I
> dont know the reasons but they decided to somehow build libpng without
> linking against libz.
> when you do: ldd /path/to/libpng.so you will get all the dependencies
> printed as a list. This works pretty fine on most systems, like on our
> ubuntu's and what not.
> On OpemBSD it prints an error message that the lib cant be loaded. But if
Tobias Leich
Aug 24, 2012, 12:58:37 PM8/24/12
to Kartik Thakore, sdl-...@perl.org
Hi, I tried exporting that machine from virtualbox, but it fails with a
stupid errormessage that I dont understand.
You cant access that box from internet, I'm sorry. I'll let you know
when I got an export of that machine.
Cheers.
Am 24.08.2012 18:21, schrieb Kartik Thakore:
>
> Ok i will twiddle with it. Do you have a freebsd machine I can ssh
> too? Or a vmware image?
>
stupid errormessage that I dont understand.
You cant access that box from internet, I'm sorry. I'll let you know
when I got an export of that machine.
Cheers.
Am 24.08.2012 18:21, schrieb Kartik Thakore:
>
> Ok i will twiddle with it. Do you have a freebsd machine I can ssh
> too? Or a vmware image?
>
> On Aug 24, 2012 4:11 AM, <em...@froggs.de <mailto:em...@froggs.de>> wrote:
>
> Hi pals!
>
> In the last time we did, in my opinion, a big mistake. In test
> scripts we checked for libpng like: SDL::Config->has('png'). But
> this didnt ever returned true, Simply because the HAVE_PNG was
> only set when actually building that lib in SDL. (Note: not
> Alien::SDL)
> This ->has() method works pretty fine for stuff like SDL_gfx,
> since it will return true if we found SDL_gfx*.h. But there was no
> check for png.h at this stage. So even if we found libpng in
> system dirs or when we build it on our own, ->has('png') never
> returned true.
>
> I changed the tests so it checks now for libpng in the shlib-hash
> that we get from Alien::SDL. This hash contains all found/build
> libs, and their path.
>
> And why does it fail then?
> BSD. LibPNG needs libz to run. Normally you would think that
> libpng is actually linked against libz, but hey, the BSD ppl dont
> think that way. I dont know the reasons but they decided to
> somehow build libpng without linking against libz.
> when you do: ldd /path/to/libpng.so you will get all the
> dependencies printed as a list. This works pretty fine on most
> systems, like on our ubuntu's and what not.
> On OpemBSD it prints an error message that the lib cant be loaded.
> But if you do LD_PRELOAD_LIBS=/path/to/libz.so ldd
>
> Hi pals!
>
> In the last time we did, in my opinion, a big mistake. In test
> scripts we checked for libpng like: SDL::Config->has('png'). But
> this didnt ever returned true, Simply because the HAVE_PNG was
> only set when actually building that lib in SDL. (Note: not
> Alien::SDL)
> This ->has() method works pretty fine for stuff like SDL_gfx,
> since it will return true if we found SDL_gfx*.h. But there was no
> check for png.h at this stage. So even if we found libpng in
> system dirs or when we build it on our own, ->has('png') never
> returned true.
>
> I changed the tests so it checks now for libpng in the shlib-hash
> that we get from Alien::SDL. This hash contains all found/build
> libs, and their path.
>
> And why does it fail then?
> BSD. LibPNG needs libz to run. Normally you would think that
> libpng is actually linked against libz, but hey, the BSD ppl dont
> think that way. I dont know the reasons but they decided to
> somehow build libpng without linking against libz.
> when you do: ldd /path/to/libpng.so you will get all the
> dependencies printed as a list. This works pretty fine on most
> systems, like on our ubuntu's and what not.
> On OpemBSD it prints an error message that the lib cant be loaded.
> /path/to/libpng.so it will work. So we have to preload the lib in
> order libpng will use it.
> Doing this needs to happen on a very early level. Doing it from
> within a running perl is to late, even if we load libpng using
> DynaLoader.
> The only thing I can think about atm is that we run a perl, load
> that libz.so, and start a child perl process that does the stuff
> we do now.
>
> This problem applies to libpng (needs libz), libtiff (needs
> libjpeg) and libvorbis (needs libogg).
> Before YAPC::EU I was working hard on that thing, I guess I can
> supply a patch in a few days.
>
> Another problem that exists right now is that the old G4-Macs dont
> have a header file we want to use, I will debug that at some
> point. I dont think that there are so many users with a G4. These
> fails only come from BinGOs so far.
>
> And there are still SDL::Controller(::Interface) fails. But since
> I dont really understand whats happening there it would be cool if
> the author (you kathekore ;o) would have a look at it.
>
> So far from me, I will write a msg about the YAPC later.
>
> See ya and take care,
> Tobias
>
> Zitat von Kartik Thakore <thakore...@gmail.com
> <mailto:thakore...@gmail.com>>:
> order libpng will use it.
> Doing this needs to happen on a very early level. Doing it from
> within a running perl is to late, even if we load libpng using
> DynaLoader.
> The only thing I can think about atm is that we run a perl, load
> that libz.so, and start a child perl process that does the stuff
> we do now.
>
> This problem applies to libpng (needs libz), libtiff (needs
> libjpeg) and libvorbis (needs libogg).
> Before YAPC::EU I was working hard on that thing, I guess I can
> supply a patch in a few days.
>
> Another problem that exists right now is that the old G4-Macs dont
> have a header file we want to use, I will debug that at some
> point. I dont think that there are so many users with a G4. These
> fails only come from BinGOs so far.
>
> And there are still SDL::Controller(::Interface) fails. But since
> I dont really understand whats happening there it would be cool if
> the author (you kathekore ;o) would have a look at it.
>
> So far from me, I will write a msg about the YAPC later.
>
> See ya and take care,
> Tobias
>
> Zitat von Kartik Thakore <thakore...@gmail.com
>
> Awesome thanks.
>
> Kartik Thakore
>
> On 2012-08-23, at 9:40 PM, Jeffrey Palmer
> <jeffrey....@gmail.com <mailto:jeffrey....@gmail.com>>
> Awesome thanks.
>
> Kartik Thakore
>
> On 2012-08-23, at 9:40 PM, Jeffrey Palmer
> wrote:
>
> Hi,
>
> I think the problem is TIFF support on BSD and Solaris, but
> FROGGS will
> know for sure.
>
> Jeff
>
> On Thu, Aug 23, 2012 at 8:49 PM, Kartik Thakore
> <thakore...@gmail.com <mailto:thakore...@gmail.com>>wrote:
>
> Hi,
>
> I think the problem is TIFF support on BSD and Solaris, but
> FROGGS will
> know for sure.
>
> Jeff
>
> On Thu, Aug 23, 2012 at 8:49 PM, Kartik Thakore
Kartik Thakore
Aug 24, 2012, 1:18:33 PM8/24/12
to Tobias Leich, sdl-...@perl.org
Cool no rush.
On Fri, Aug 24, 2012 at 12:58 PM, Tobias Leich <em...@froggs.de> wrote:
> Hi, I tried exporting that machine from virtualbox, but it fails with a
> stupid errormessage that I dont understand.
> You cant access that box from internet, I'm sorry. I'll let you know when
> I got an export of that machine.
>
> Cheers.
>
> Am 24.08.2012 18:21, schrieb Kartik Thakore:
>
> Ok i will twiddle with it. Do you have a freebsd machine I can ssh too? Or
> a vmware image?
>> Zitat von Kartik Thakore <thakore...@gmail.com>:
On Fri, Aug 24, 2012 at 12:58 PM, Tobias Leich <em...@froggs.de> wrote:
> Hi, I tried exporting that machine from virtualbox, but it fails with a
> stupid errormessage that I dont understand.
> You cant access that box from internet, I'm sorry. I'll let you know when
> I got an export of that machine.
>
> Cheers.
>
> Am 24.08.2012 18:21, schrieb Kartik Thakore:
>
> Ok i will twiddle with it. Do you have a freebsd machine I can ssh too? Or
> a vmware image?
>>
>> Awesome thanks.
>>>
>>> Kartik Thakore
>>>
>>> On 2012-08-23, at 9:40 PM, Jeffrey Palmer <jeffrey....@gmail.com>
>> Awesome thanks.
>>>
>>> Kartik Thakore
>>>
>>> On 2012-08-23, at 9:40 PM, Jeffrey Palmer <jeffrey....@gmail.com>
>>> wrote:
>>>
>>> Hi,
>>>
>>> I think the problem is TIFF support on BSD and Solaris, but FROGGS will
>>> know for sure.
>>>
>>> Jeff
>>>
>>> On Thu, Aug 23, 2012 at 8:49 PM, Kartik Thakore <
>>>
>>> Hi,
>>>
>>> I think the problem is TIFF support on BSD and Solaris, but FROGGS will
>>> know for sure.
>>>
>>> Jeff
>>>
>>> On Thu, Aug 23, 2012 at 8:49 PM, Kartik Thakore <
0 new messages