t/examples/library.t - pcre check flawed

[coke]

config/auto/pcre.pm controls whether parrot is configured with pcre or not; however t/examples/library.t simply calls 'pcre-config' instead of asking parrot if it was configured with PCRE.

This causes the test to fail if a version of pcre-config is available but not suitable for usage with the parrot PCRE library.

Test should be updated to respect the parrot config instead of checking again.

[jkeenan]

See also  RT #44763: Assertion fails if PCRE is not available.

[coke]

Test skipped in r37497.

[coke]

This also affects the test in t/library/pcre.t - the pcre test in library.t should be moved to that file (assuming it's not a duplicate)

[coke]

Replying to coke:

This also affects the test in t/library/pcre.t - the pcre test in library.t should be moved to that file (assuming it's not a duplicate)

Looking at the test, makes sense to keep them separate. (one is testing the library, one is test the example (that uses the library))

[jkeenan]

Check Parrot configuration data before running test of PCRE

[jkeenan]

I have attached a patch ... but one that is so simple I can't believe no one thought of it in the past four months:

Index: t/examples/library.t
===================================================================
--- t/examples/library.t        (revision 40067)
+++ t/examples/library.t        (working copy)
@@ -57,7 +57,7 @@
 
 SKIP:
 {
-    skip( 'no pcre-config', 1 ); # Original check for PCRE flawed (TT #406)
+    skip 'no pcre-config', 1 unless $PConfig{HAS_PCRE};
 
     my $pcre_fn  = File::Spec->catfile(qw( examples library pcre.pir ));
     my $test_out = `$PARROT $pcre_fn asdf as`;

For me, the test is skipped on Darwin/PPC, where HAS_PCRE is 0, but is run -- and passes -- on Linux/i386 where HAS_PCRE is 1.

kid51

[NotFound]

I added a test for the library loading and initialization in r40353

[NotFound]

In r40354 I added attempts to ldopen using the names libpcre.so and libpcre.so.3 if the plain libpcre fails. I think the last attempt will fix the problem, not because of the soname of the library but because of a dynamic link with that name exists, and the libpcre.so link is provided by the libpcre devel packages, not the plain libpcre ones, in a lot of systems.

This is a generic problem for runtime linking, pkg-config and friends are intended for compile time linking, not for dlopen'ing. Anyway, providing the major version number of the intended library is not such a bad thing, it can avoid attempts to use abi incompatible versions.

[jkeenan]

It appears that no one has complained in 19 months about the patch I applied.

So I am taking the ticket and will close it in 2-3 days unless someone objects.

Thank you very much.

kid51

[jkeenan]

No comments or complaints received in the 3-day period. Closing.

Thank you very much.

kid51