|
in reply to Re: EU::MM again.
in thread EU::MM again.
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;
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";
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.
|
Re^3: EU::MM again.
by syphilis (Archbishop) on Mar 25, 2009 at 22:20 UTC
|
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] |
Re^3: EU::MM again.
by grinder (Bishop) on Mar 25, 2009 at 20:29 UTC
|
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] |
|
|
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?
Because WriteMakefile() does the remapping internally, to cope with the vagaries of compiler and linker idiosyncracies. Had you read the documentation to which I linked, you wouldn't be asking this question.
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.
Okay, so I wrote libpq when I meant to say -lpq is, jeez, cut me some slack. Are you being deliberately obtuse? I thought it was obvious that you had to change that part with an interpolation of either -lpq or -lpq64 depending on the result of some platform test (of which I incorrectly assumed you were a past master).
See: ["-L$POSTGRES_LIB -lpq -lm"]--libpq is NOT MENTIONED! -lpq is there (along with -lm, whatever that is?), but not libpq.
And to think you were almost there.
I was hoping that someone who has been through the problem would point me in the right direction, rather than just random guesses.
There was nothing random, nor were they guesses, and I pointed you in precisely the correct direction. I know this stuff. I admit to being a bit light on specific details; I thought you would have been smart enough to fill in the blanks. You're not exactly a newbie, otherwise I would have filled in more blanks for you.
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.
I'll keep that in mind next time.
• another intruder with the mooring in the heart of the Perl
| [reply] |
|
|
|
|
