Robin Bowes wrote:
> kdf wrote:
>> Quoting 0xdeadbeef
>> <[EMAIL PROTECTED]>:
>>
>>
>>>
>>> cjk32 Wrote:
>>>> slimserver.pl certainly does attempt to set up @INC to contain the
>>>> 5.8.x paths followed by 5.8.
>>>>
>>>> From the looks of it, it seems to use ONLY 5.8.x. Else if would
>>>> find
>>> the "missing" directories, wouldn't it?
>>> Well, apparently, there is something broken regarding include paths
>>> and I'm a little puzzles why this isn't considered an error...
>>
>> not one person has said it wasn't, but if it makes you feel better
>> something is an error. Ee're just discussing the actual problem, to
>> find out WHAT is the error. See bug 3324.
>>
>> Many other modules fallback to 5.8 just fine, so there is more to it.
>
> I've noticed that slimserver uses modules from the slimserver
> directory in preference to any system-installed modules.
>
Is this not intentional? Quoting from slimserver.pl:
# This works like 'use lib'
# prepend our directories to @INC so we look there first.
unshift @INC, @SlimINC;
I've attached a patch under bug 3324 that attempts to force slimserver.pl to
load all interdependent modules from the same place. I was finding that by
crippling the GD binaries in slimserver CPAN directory, I could get GD.pm
loaded from the system CPAN, and GD::Image and GD::Polygon loaded from the
slimserver CPAN or vice versa. In the second case, I got symptoms that
appear to be identical to those described earlier on this thread.
Specifically, 'require GD;' succeeding, but 'GD::Image->can(jpeg);' returing
false. On my system, the patch means that GD comes completely from one CPAN
or the other, and resizing works in both cases.
Chris Key
_______________________________________________
beta mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/beta
