What steps will reproduce the problem? 1. go here: http://www.veola.net/macintosh/adding-gd-library-for-mac-os-x-leopard 2. rebuild PHP with GD 3. set the gd.so module on.

What is the expected output? What do you see instead? The right side <where the content of the selected function should appear> is white blank.

What version of the product are you using? On what operating system? last version: 0.9.6.2b OS X.5.2 updated to: 29 March 08

Please provide any additional information below. when disabling the module in the php.ini file the widget return to work, but i do need the widget, and do need the GD =)

Hi. Thanks for taking the time to file this bug report. If you could, would you mind checking out the latest development release and letting me know if you have the same problem? Cheers, -Andrew

Hi, you welcome! the new version is awesome, but still... many more bugs :| Its keeps loading, when i try to set the radio button to English, and then pressing "done" its still loading...

after i refresh the widget i can see the Preferences isn't saved, and by the way i delete the old preferences file, and a new file is never created.

see the Attached files.

Hi again. Looks like you're on a version a few revisions ago. Try updating and see if you get those same errors. Regards, -Andrew

Sorry, I should be more clear. You are probably using the latest download. If you get the widget from SVN, you'll see heaps of bug fixes and new features. -Andrew

yeah i downloaded the version attached to the google code, but not from the SVN. i'll do CheckOut now.

Well the new one is cool, with the downloader and installer but it doesnt work either. only when i disable the GD

OK, thanks for checking that out! I'll see what I can do about it.

Handing this off to Kelly to see if he can track down the cause.

Hey guys,

I think GD mess-up with STDIN / STDOUT or... maybe with fwrite / fread when I disable it all the data can be reached, when it enable no property is assign the the global vers, which cause the errors.

any luck? :-| I'm not sure which I contact, PHP dev? GD dev?

Thanks.

I haven't heard from Kelly on whether he's made any progress with this bug. But, I did just commit a new version that fwrites to STDOUT rather than echoing the content from the PHP scripts the widget runs to return the HTML for the function pages.

Try a svn co of revision 79 and let me know here if it makes any difference. Thanks!

cool i will :)

I'm at rev 80 using svn update, no change.

Thanks!

OK After digging inside the code i found this:

when i run manually in the terminal this line: /usr/bin/php 'Assets/php/installed.php' when the GD is off i get this Array : ["en"] which is good!

when GD is running i get this error: dyld: NSLinkModule() error dyld: Symbol not found: _php_sig_gif Referenced from: /usr/lib/php/extensions/no-debug-non-zts-20060613/gd.so Expected in: dynamic lookup

Trace/BPT trap

Thanks for the error message. I'm not sure how to follow-up on that as it appears to be a bug in either the GD library or in Dashboard's interface to PHP.

Kelly, is this something you can delve into further?

i found something in apple discussion about php CLI unsupport dynamic links.

I'll try to install 5.2.5 beta 6 of Entropy and see if that fix this problem

thats the main issue = "indeed seems to be that the CLI version of pph5 which Apple supply hasn't got the capability to load dynamic libraries."

when GD is off i guess that PHP doesn't need to load any dynamic link so there is no error, but when GD is on PHP have to try to link to it, and it kills the widget :|

OK I FIXED IT , and I have to suggest somthing in order to avoid this kind of problems. the widget was looking for /usr/bin/php to run in CLI

so after noticing this i used remove the PHP from this dir and make a Symblink to the /usr/local/php5/bin/php that I have downloaded from entropy.

so in order to avoid these kind of things I think you need somehow if there is a folder for php inside usr/local or to check which version and from where the PHP is runing and use the actual CLI version of this active PHP version, and not using by default the /usr/bin/php version.

Thanks for your help! I'm enjoying using your Widget!

Good news! The latest versions of PHPfr have a setting on the back that allows you to indicate the path to the PHP binary you want to use. This should effectively work around this bug.

Thanks for ALL of your efforts researching a workaround for this bug! I'd like to include your name and a link to your website (if you have one) in the credits for the widget, so send me that if you want to be recognized for your work on this issue!

Hi segdeha,

It appear that the widget do not save the php path , after refreshing the widget, the php path goes back to /usr/bin/php.

about the Credit, well I'm just so happy about making this widget working again!!! but of course it will be great if you add this to the credits website address: www.macpire.com nickname: Macpire

I have another issues to report but ill use different issue card.

Thanks!

Roded.

The path to the PHP binary is set so it is now saved as a preference, so it is preserved between reloads of the widget.