perlinformixmake-install

Make error installing DBD::Informix module


I am running the make on the DBD::Informix module and I am getting an error that it can't create the Informix.so file. If you take a look at the first step it did for the make it removed the original Informix.so file. But it looks like an environment variable that has a value of "/usr/bin/perl" is being appended to the path so it is not able to create (make) the new Informix.so file.

Has anyone seen this before? It looks like INFORMIXC is the variable that's being appended to it. Can I change this? I tried the suggestion in this article from CPAN and downgraded to that module but no luck.

Error

/opt/informix/bin/esql: line942: /home/pdoug/.cpan/sources/authors/id/J/JO/JOHNL/DBD-Informix-2013.0521/"/usr/bin/perl": No such file or directory
make: *** [blib/arch/auto/DBD/Informix/Informix.so] Error 127



[root@sandbox-support DBD-Informix-2013.0521]# make
rm -f blib/arch/auto/DBD/Informix/Informix.so
INFORMIXC='"/usr/bin/perl" esqlld' ESQLLD='gcc -shared -O2 -g -pipe -Wall   -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector-strong --param=ssp-  buffer-size=4 -grecord-gcc-switches -m64 -mtune=generic -Wl,-z,relro ' esql    -shared -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-    protector-strong --param=ssp-buffer-size=4 -grecord-gcc-switches -m64   -mtune=generic -Wl,-z,relro  Informix.o dbdimp.o dbdattr.o sqltoken.o sqltype.o ixblob.o odbctype.o kludge.o link.o esqlcver.o esqlc_v6.o  -o  blib/arch/auto/DBD/Informix/Informix.so      \

Installed version 6.66 as recommended from a similar issue and it didn't fix the issue

Writing /root/.cpan/Metadata

ExtUtils::MakeMaker

    (no description)
    B/BI/BINGOS/ExtUtils-MakeMaker-7.04.tar.gz
    /root/perl5/lib/perl5/ExtUtils/MakeMaker.pm
    Installed: 6.66
    CPAN:      7.04  Not up to date
    Chris Williams (BINGOS)
    chris@bingosnet.co.uk

Solution

  • I'm the maintainer of DBD::Informix. This is a problem I'm (uncomfortably) aware of.

    Those who maintain ExtUtils::MakeMaker made a change to the handling of a pathname (I forget exactly which one; I think it is the value of the make macro FULLPATH) and they now enclose it in double quotes which evidently doesn't matter for their expected uses of the value, but it breaks DBD::Informix. When I started with DBD::Informix (sometime towards the end of the last millennium), there were all sorts of weirdnesses that had to be dealt with. There are still, probably, a moderate number of them. So I have a complex system to code around the fact that people use GCC to build Perl but the ESQL/C product expects to use an alternative compiler. Said workaround worked OK from 1997-2014 or thereabouts; it has now been broken. I'm not happy about this. I haven't yet worked out a good solution to the problem.

    If you don't mind being a guinea pig, you could make a backup copy of Makefile.PL, and then apply this patch to it:

    patch --dry-run --verbose <<'EOF'
    --- Makefile.PL 2013/05/22 05:40:27 2013.5
    +++ Makefile.PL 2015/08/20 22:40:59
    @@ -710,7 +710,7 @@
     # the files list...
    
     # Default version of $opts{LD}
    -$opts{LD} = "INFORMIXC='\$(FULLPERL) esqlld' " .
    +$opts{LD} = "INFORMIXC=\"\$(FULLPERL) esqlld\" " .
                 "ESQLLD='$Config{ld} \$(LDDLFLAGS)' \$(ESQL)";
    
     my $esql_nt = "";
    EOF
    

    The patch code above does a dry-run; it checks whether the patch could be applied. If that works (no warnings or errors), then remove the --dry-run option. Then run the normal build process:

    perl Makefile.PL &&
    make &&
    make test &&
    : make install  # If you're brave; eventually, you do make install
    

    The modified Makefile.PL seems to work for me (Perl 5.22.0 on Mac OS X 10.10.0, with CSDK 3.70.FC4), but I'm not yet sure it is all that kosher. What it does is gives you two adjacent double quotes, which the shell maps to an empty (and quoteless) string.

    Update: DBD::Informix version 2015.0826 released

    On 2015-08-26, DBD::Informix version 2015.0826 was released and uploaded to CPAN. This incorporates what should be a permanent fix to the problem evaded by the patch above (the change is more significant, but also safer in most respects).