Project

General

Profile

Bug #23276

Perl tests do not use the in-tree lblasso.so which makes the test meaningless

Added by John Dennis over 6 years ago. Updated about 6 years ago.

Status:
Fermé
Priority:
Normal
Category:
Binding perl
Target version:
Start date:
19 April 2018
Due date:
% Done:

100%

Estimated time:
Patch proposed:
No
Planning:

Description

The C based tests and the Java tests carefully make sure they are running against the liblasso that was built in the tree, however the perl test does not do that. The net result is the perl test ends up loading the system version of liblasso and not the one in the tree. So if you're trying to test what you've built it's not giving you meaningful results.

For example:

% cd bindings/perl
% make check

Due to a symbol change in liblasso test fails with this error:
Can't load '/home/jdennis/src/lasso/bindings/perl/blib/arch/auto/Lasso/Lasso.so' for module Lasso: /lib64/liblasso.so.3: undefined symbol: xmlSecSoap12GetBody at /usr/lib64/perl5/DynaLoader.pm line 193.

The failure is due to the fact the system version of liblasso has an undefined reference to that symbol which cannot be resolved by libxmlsec. But that symbols is not in the in-tree version of liblasso. Forcing the test to use the in-tree version of liblasso like this causes the test to succeed.

LD_LIBRARY_PATH=../../lasso/.libs make check

I tried to figure out how to add LD_LIBRARY_PATH into Makefile.perl but MakeMaker is sufficiently opaque that I gave up.

Associated revisions

Revision aace9d31 (diff)
Added by Benjamin Dauvergne about 6 years ago

perl: force use of the in-tree lasso when running tests (fixes #23276)

History

#1

Updated by Benjamin Dauvergne over 6 years ago

Does this patch fix your problem ?

diff --git a/bindings/perl/Makefile.PL b/bindings/perl/Makefile.PL
index 5383d63e..8ac6947d 100644
--- a/bindings/perl/Makefile.PL
+++ b/bindings/perl/Makefile.PL
@@ -2,10 +2,10 @@ use 5;
 use ExtUtils::MakeMaker;

-if (not grep /^LIBS=/, @ARGV) {
-       $LIBS=`pkg-config --libs lasso 2>&1`;
-       die "pkg-config cannot find lasso" if $?;
-}
+#if (not grep /^LIBS=/, @ARGV) {
+#      $LIBS=`pkg-config --libs lasso 2>&1`;
+#      die "pkg-config cannot find lasso" if $?;
+#}

 WriteMakefile(
     NAME              => 'Lasso',

On my computer (Debian sid) it uses the lib from the source not the one from the system with or without these lines.

#2

Updated by John Dennis over 6 years ago

Thank you Benjamin, but no it does not fix it. I even tried this in Makefile.PL

$LIBS="../../lasso/.libs";

But that didn't work either and since I don't fully understand what is happening in the perl directory I'm concerned something like that might affect what is installed as opposed to what is done during "make check". I think, but I'm not 100% sure that passing $LIBS is what is needed for the installed version (but it probably will work without it).

The problem seems to be in this part of the generated Makefile.perl

test_ : test_dynamic
    $(NOECHO) $(NOOP)

subdirs-test_dynamic :: dynamic pure_all

test_dynamic :: subdirs-test_dynamic
    PERL_DL_NONLAZY=1 $(FULLPERLRUN) "-I$(INST_LIB)" "-I$(INST_ARCHLIB)" $(TEST_FILE)
    PERL_DL_NONLAZY=1 $(FULLPERLRUN) "-MExtUtils::Command::MM" "-MTest::Harness" "-e" "undef *Test::Harness::Switches; test_harness($(TEST_VERBOSE), '$(INST_LIB)', '$(INST_ARCHLIB)')" $(TEST_FILES)

But I haven't done anything with Perl for almost 15 years now and my Perl expertise has atrophied. But I think somewhere in the test_dynmaic target it needs to force the use of the in-tree library. But I don't have enough understanding of how all the moving pieces in MakeMaker work to accomplish this.

#3

Updated by Benjamin Dauvergne about 6 years ago

John Dennis a écrit :

But I haven't done anything with Perl for almost 15 years now and my Perl expertise has atrophied. But I think somewhere in the test_dynmaic target it needs to force the use of the in-tree library. But I don't have enough understanding of how all the moving pieces in MakeMaker work to accomplish this.

I'm also rusty myself on Perl, I dived deep in the internals when writing the binding but I lost all my knowledge since then. Binding was produced for free software IdP LemonLDAP::NG but they don't have the ressource to maintain it either.

#4

Updated by John Dennis about 6 years ago

I can't see any way to get the Makefile produced by MakeMaker to use the in-tree version of liblasso just for the unit test. As such this has to be fixed some other way. The best solution I could come up with is to add LD_LIBRARY_PATH=../../.libs inside test.sh which invokes the Perl Makefile to run the test (see below patch). It's less than ideal because it's hardcoded rather than using the configuration produced by autotools. I suppose configure could produce a test.sh from a test.sh.in file but I don't see much value in doing this extra work because quite a bit of the test code already has hardcoded references to ../.libs or ../../.libs. Though some magic I don't yet understand the Java binding has .libs copied into it. Anyway all this is say hardcoding LD_LIBRARY_PATH=../../lasso/.libs in test.sh is no worse than what the other bindings are doing.

diff --git a/bindings/perl/test.sh b/bindings/perl/test.sh
index 907080d1..e2e208cd 100755
--- a/bindings/perl/test.sh
+++ b/bindings/perl/test.sh
@ -1,2 +1,2 @
#!/bin/bash
-make -f Makefile.perl test
+LD_LIBRARY_PATH=../../lasso/.libs make -f Makefile.perl test

#5

Updated by Benjamin Dauvergne about 6 years ago

  • Status changed from Nouveau to Résolu (à déployer)
  • % Done changed from 0 to 100
#6

Updated by Benjamin Dauvergne about 6 years ago

  • Target version set to 2.6.0
#7

Updated by Benjamin Dauvergne about 6 years ago

  • Status changed from Résolu (à déployer) to Fermé

Also available in: Atom PDF