At 04:58 23-3-2002, Kevin Atkinson shared with all of us:
>Um, The Old Aspell/Pspell had the exact same problem. The only requirement
>is that the libstdc++ somehow gets linked in the the php binary.
Ok.
> >
> > I don't know for sure if it works ok, but I'll
> > make some test-cases to see if it does.
>
>OK. Let me know. This will be the first real test of the New Aspell in
>an application.
Well - the strangest thing:
-- it compiles,
-- it links into the php binary (CLI/CGI version to allow tests)
-- but php -m to list all the modules gives:
$ ./sapi/cli/php -m | grep spell
nuttin!
$ ldd ./sapi/cli/php | grep spell
libaspell.so.15 => /weblib/local/lib/libaspell.so.15 (0x483c2000)
libaspell-common-0.50.so =>
/weblib/local/lib/libaspell-common-0.50.so (0x48445000)
> > I also don't know, if PSpellConfig is the right
> > function to test for in the old library (the old
> > config.m4 didn't test for any library, just for
> > the header).
>
>Hum, are you trying to automatically determine is the library is the "New
>Aspell" or if it is Pspell?
Yes, because the new aspell needs to be linked with libaspell rather than
libpspell. Maybe that's the problem here. I think it tries to load
libpspell hardcoded.
I'll see if I can fiddle with that a bit.
From the old pspell lib, I would need a 'T'-type symbol, that I can test
for, or use AC_TRY_LINK with some headers, but that's what I want to avoid.
Best regards,
Melvyn Sopacua
WebMaster IDG.nl
_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
If it applies, where it applies - this email is a personal
contribution and does not reflect the views of my employer
IDG.nl.
\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\
