On Thursday 01 May 2008 12:07:47 Alberto Simões wrote: > There was a test (test three from t/examples/library.t) that was failing > and failing under MacOS X. That test relies on libpcre that is not > available by default on MacOS X.
It seems to me that the test should skip itself if dynamic loading of libpcre fails. > If you use MacPort to install the library, it will be placed under > /opt/local/lib. The configure step I added to the configure system will > detect it, but the test will fail, because pcre.pir can't locate the > library. > > My current solution was to export DYLD_FALLBACK_LIBRARY_PATH including > the /opt/local/lib path, but I think this is not a good solution. I don't know much about Mac OS X, but there should be a way to add this path to the list of paths ld.so (or the Darwin equivalent) searches. > If we are going to rely on DYLD_FALLBACK_LIBRARY_PATH, we should make a > configure step to check if all libraries that will be loaded dynamically > are available using the current DYLD_FALLBACK_LIBRARY_PATH. > > The other option, might be a -L flag to parrot, so we can add those > extra library paths there. This second solution would also need a > configure step to find out which libraries paths should be used for each > test. > > I think this might happen as well for Linux, and LD_LIBRARY_PATH. I'm not sure. Why add special logic to Parrot to find poorly-installed libraries? If you install a dynamic library outside of your normal system library paths, no other program will find it. If you want other things to find it, add it to your paths, or add its path to your list of dynamic loading paths. I vote for fixing the buggy test (no pcre, no reason to run the tests) but not working around standard dynamic library loading. -- c
