http://qs321.pair.com?node_id=753047


in reply to EU::MM again.

Can anyone offer pointers?

I may be being thick (it wouldn't be the first time) and thus be missing a subtle point to your question, but what you want to do is quite simple:

my @lib_flags = qw(this that other);

if (running_on_64bit()) {
    push @lib_flags, 'libpq64.lib';
}
else {
    push @lib_flags, 'libpq.lib';
}

# ... time passes

WriteMakefile(
    NAME => 'DBD::Pg',
    LIBS => ["@LIB_FLAGS"],
    ...
);

[download]

The reference to a stringified array is a little weird, I'll grant you that. But it should work. Looking at the Makefile.PL, it seems that setting the POSTGRES_LIB environment variable should work out of the box.

• another intruder with the mooring in the heart of the Perl

Replies are listed 'Best First'.
Re^2: EU::MM again.
by BrowserUk (Patriarch) on Mar 25, 2009 at 16:02 UTC
    but what you want to do is quite simple: ...

    Hm. The only reference in Makefile.pl to libpq the following which comes after WriteMakeFile() has been called, and is used to check if it was detected (It is; I get no errors): 

    my $output = WriteMakefile(%opts);
if (!exists $output->{EXTRALIBS} or
    ($output->{EXTRALIBS} !~ /\-lpq/ and $output->{EXTRALIBS} !~ /libp
+q/)) {
    my $makefile = exists $output->{MAKEFILE}
        ? "\nRemoving ($output->{MAKEFILE})\n" : '';
    warn qq{
==========================================================
WARNING! No libpq libraries were detected!
You need to install the postgresql-libs package for your system,
or set the POSTGRES_LIB environment variable to the correct place.
$makefile
===========================================================
};
    ## Do not let make proceed
    unlink $output->{MAKEFILE} if $makefile;
    exit 1;
}
exit 0;

    [download]

    And the only references to the key LIBS in %opts as passed to WriteMakeFile() are these: 

         LIBS           => ["-L$POSTGRES_LIB -lpq -lm"],
...
elsif ($os =~ /Win32/) {
    my $msdir = $POSTGRES_LIB;
    $msdir =~ s{"$}{/ms"};
    $opts{LIBS}[0] .= " -L$msdir -lsecur32";

    [download]

    So, I guess the "subtle point to my question" is how (and where/when) does -lpq get manipulated to cause it to add the reference to -llibpq?

    On the basis that it EU::MM might simply generate references to all .libs it finds in the directory denoted by $ENV{ POSTGRES_LIB }, I tried placing a copy of libpq64.lb there, but it is ignored. As are the other .lib files that are located there: postgres.lib, libpgport.lib; libecpg.lib;.

    So, something, somewhere, is telling EU::MM to generate references to libpq.lib, but I cannot see where or when that is occuring.

    The second part of my question was how to automate the choice of whether to use libpq.lib or libpq64.lib. Your pseudo-code above neatly dodges both parts of that question.

    • What goes inside your running_on_64bit()?

      Ie. How to reliably determine that the target is X64 (on Windows).

    • Where in the makefile.pl would I position your pseudo-code?

      Given I can't see where libpq.lib is being referenced (other than in the post-facto test), it's hard to see where I would incorporate your code.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]
      how (and where/when) does -lpq get manipulated to cause it to add the reference to -llibpq

      You compiler (cl) doesn't understand the -l switch, so MakeMaker converts the -lpq to libpq.lib in order that your compiler will be able to make use of it. Changing the -lpq to -lpq64 in the LIBS assignment should fix things for you.

      Cheers,
      Rob
[reply]
[d/l]
[select]
[reply]
      So, I guess the "subtle point to my question" is how (and where/when) does -lpq get manipulated to cause it to add the reference to -llibpq?

      Ah, that is handled ExtUtils::Liblist which is invoked by WriteMakefile() itself. It should Just Work.

      ["-L$POSTGRES_LIB -lpq -lm"]

      Right, so libpq is hardcoded into the LIBS key's value. You shall have to interpolate something in its place instead. (Hence my conditional construct in my first snippet).

      The second part of my question was how to automate the choice of whether to use libpq.lib or libpq64.lib. Your pseudo-code above neatly dodges both parts of that question.

      And here I was hoping you wouldn't notice. I blithely assumed that this would be trivial for you. So... as for knowing whether you're on 64-bit or not, my next thought would then be to rummage through %Config and see what turns up. Other than that, I honestly don't know. But Dave "DrHyde" Cantrell would surely be happy to take on board any code you figure out, and place it in Devel::CheckOS for others to use.

      As to where you put this code, it has do be sorted out before WriteMakefile() gets called. That DBD::Pg grovels through the resulting Makefile afterwards sounds like a dreadful hack of the highest order. Also I don't know what App::Info does these days; I haven't been keeping up with the mailing lists to keep track.

      • another intruder with the mooring in the heart of the Perl

[reply]
        Ah, that is handled ExtUtils::Liblist which is invoked by WriteMakefile() itself. It should Just Work.

        No. It doesn't. I can't. There is no 64-bit version of Pg available, only the 32-bit version. Which means that the lib files distributed with it are all 32-bit.

        I wish to use the 32-bit Pg from 64-bit Perl, so I had to build 64-bit versions of libpq.lib and libpq.dll. But I cannot just replace the 32-bit versions with the 64-bit versions, because if I build any 32-bit apps that need those libraries, I will need the 32-bit versions available. So, I've chosen to use the names libpq64.lib & libpq64.dll, so that both can coexist on my system.

        So, please explain to me how (or rather, why you wrongly think that) "It should Just Work."? How could it possibly know to use files, that I've chosen the names for?

        Right, so libpq is hardcoded into the LIBS key's value.

        Look again. No it isn't. If it was, I wouldn't have had to post my question.

        See: ["-L$POSTGRES_LIB -lpq -lm"]--libpq is NOT MENTIONED! -lpq is there (along with -lm, whatever that is?), but not libpq.

        So, how can I conditionally interpolate something in its place instead, when it doesn't currently have a place for me to change?

        But Dave "DrHyde" Cantrell would surely be happy to take on board any code you figure out, and place it in Devel::CheckOS for others to use.

        I wouldn't use that steaming pile of O'Woe if you paid me to. Even if it was applicable, which it isn't. The problem of determining which of libpq.lib or libpq64.lib to use, has exactly nothing to do with OS you are running under.

        The problem is determining which environment this compilation is targeting--x86, or x64. You can target either when running under Win32 or Win64. How you determine which is being targeted, at runtime from within the Makefile.pl is the (other) problem I was hoping to get help with.

        I know for instance, that when syphilis was testing my version of Devel::Size on Win64, he had problems finding a suitable test for the target environment--and he has far more experience building for win64 than I do. I only just got my new system--hence the reason for asking here.

        I was hoping that someone who has been through the problem would point me in the right direction, rather than just random guesses.

        At this point, your replies have done exactly zero to assist me, but given their plausible and somewhat dismissive tone, have probably prevented others from actively considering the problems.

        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom