chromatic wrote:
I vote for fixing the buggy test (no pcre, no reason to run the tests) but not
working around standard dynamic library loading.
It is not that easy (I think). Also, I do not know much about these
things, so let me try explain some more details.
1) the configure step finds pcre correctly (using macports specific
code). Thus, pcre exists on the system.
2) the library is not installed in a precarious place. We are talking of
one of the two major ways MacOS people have to install software (find
and macports), both of which will have this problem.
3) there are other libraries (like ICU) that are on the same place.
Parrot gets linked with it, and works without any kind of environment
variable. This should mean that gcc stores the path somewhere, I would say.
4) that I know (and I readed dyld man page) there isn't a ld.so.conf or
whatever under MacOS.
As this is not just a problem that affects one test, but will affect all
dynamic library loading that is not Apple standard, I think we should
look to it with some care. Also, note that some standard modules, like
OpenGL, are doing this by brute force, testing specific hard-coded
libraries. That is not at all a good option.
Cheers
ambs
--
Alberto Simões - Departamento de Informática - Universidade do Minho
Campus de Gualtar - 4710-057 Braga - Portugal
