[asterisk-dev] Still running into build issues w/ trunk, bug 17720

[Philip Prindeville]

  On 7/29/10 1:57 PM, Kevin P. Fleming wrote:
> On 07/29/2010 03:39 PM, Philip Prindeville wrote:
>>    
>> So what I've written above is inflammatory and over-the-top?  Huh.
> The portions I snipped out were, yes. If you can restrain yourself to
> constructive criticism and useful proposals, rather than whinging about
> the state of the world and your feelings about other people's attitudes,
> resource availability and other topics, it's likely the conversation
> will be much more productive.
>
>>> What I said was if you have installed a different version of postgres on
>>> your system (in any place you care to install it), that installation
>>> will include a pg-config tool (unless you've done something to stop that
>>> from happening). That pg-config tool is what the configure script will
>>> consult to learn how to compile against and link to the libraries
>>> provided by that installation of postgres. If telling the configure
>>> script where that pg-config tool lives does not produce a build that
>>> actually uses that installation of postgres, then that is a bug...
>>> assuming that the pg-config tool in that location works properly and
>>> reports the proper information.
>>>
>> Yes, it "works properly" at target RUN-TIME.  It doesn't work properly at COMPILE-TIME on the host.
>>
>> That's the nature of cross-building.
>>
>> It's not a bug, it's just that the tool has limitations that didn't anticipate being used in this scenario.
> Then what you are asking is for us to work around limitations of a tool
> that is provided for our use, rather than fixing the tool. As best I can
> tell, pg_config provides no facility to prefix the paths it outputs with
> the build root you've installed it into, which makes it nearly
> impossible to use in your environment. The proper solution to this
> problem is modify that tool to accept a '--destdir' or similar option,
> that it would use to prefix paths that it outputs that are to be used at
> compile time and link time, but not at run time.
>

And this is the point that I've been trying to make.  That pkg-config is useless in cross-build environments.

We're now on the same page.

Perhaps you've been reading as "whinging" what I was trying to convey as a simple matter-of-fact.

Another workaround would be to allow the user to directly specify the parameters that would otherwise be extracted from pg-config (in this case PGSQL_INCLUDE and PGSQL_LIBDIR, I think) directly at the command line, and skip running pg-config if they've already been specified.

I would also bracket any calls to running *-config with: test x$ac_cross_compile = "xno"