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

[Philip Prindeville]

  On 7/29/10 1:05 PM, Kevin P. Fleming wrote:
> On 07/29/2010 02:14 PM, Philip Prindeville wrote:
>>    On 7/29/10 11:38 AM, Kevin P. Fleming wrote:
>>> On 07/29/2010 01:27 PM, Philip Prindeville wrote:
>>>>     Filed this bug:
>>>>
>>>> https://issues.asterisk.org/view.php?id=17720
>>>>
>>>> In short, the current autoconf setup doesn't allow you to manually specify values (like PGSQL_INCLUDE) as parameters to ./configure...  It detects pg-config and grabs everything from there.
>>> It's never going to allow you to specify PGSQL_INCLUDE. The configure
>>> script relies on pg-config providing the correct values to be used, so
>>> the only input you have into the process is telling the configure script
>>> where pg-config can be found (or which version should be used).
>> Why not allow the user as much granularity of control as he wants?
>>
>> If he specifies the path explicitly, then pg-config isn't even needed.
> Yes, it is. pg-config (as do all pkg-config-based tools) have the
> ability to provide much more information than just the location of the
> relevant header files and libraries. We don't want that information
> embedded in the configure script if it's not necessary, because it will
> just go out of date and cause build problems. For many libraries we have
> no choice, but for some libraries where the library provider gives us a
> tool to learn what we need, we absolutely want to use that tool to get
> the information.
>
> For a user who wants to override what the configure script does, there
> is a method already available: edit the makeopts file that is generated
> to make PGSQL_INCLUDE and PGSQL_LIB point have whatever contents you
> like. It's not in our best interests to attempt to build a configure
> script that can accommodate any possible usage model, no matter how
> complex. The configure script is a helper, and everything that it does
> can already be done via other means, so for those complex scenarios the
> 'helper' will not be of as much use as it could be.

And that's nearly feasible, except that PGSQL_INCLUDE is being overloaded with both -I include path instructions as well as compiler directives.

Yes, I could use some sed regex to substitute out just the relevant portion... in this case -I/usr/include... and replace it with our path...  But just pointing out that PGSQL_INCLUDE is being overloaded and this would be simpler and cleaner if two separate variables were used.

I'll also point out that if you try to turn on postgres linkage, but it finds the system version, then the configure script will fail because it will try to link binaries of the wrong architecture into a conftest.c intermediate binary... so the configure process will fail and you won't end up with makeopts that you can simply "fix up" after the fact.

You'd have to explicitly build it without postgres, then manually reinsert everything back in that's needed to enable postgres to build... (including #define HAVE_whatever).


>>>> This is both a problem when cross-building, and when you have a private local library build of Postgres that you want to link and test against... and you don't want it seeing the host headers/libraries.
>>>>
>>>> This also affects more than just Postgres, it's a repeat of the issue we were seeing with netsnmp in 16991.
>>>>
>>>> Do we want to fix this in 1.8?
>>>>
>>>> And do we want to fix this piecemeal, or overhaul the autoconf stuff and scrub it clean in one go?
>>>>
>>>> I'd rather put this puppy to bed, because it keeps coming up in multiple manifestations, but it's not my call of course.
>>> It should be fixed, if the correct version of pg-config is being called
>>> but the output of that tool is not being properly utilized in the build
>>> process. If there is no correct version of pg-config, or the version
>>> that is pointed to does not produce the correct output, then the failure
>>> is in the system installation, not in Asterisk's configure script.
>>>
>> Here we disagree.
>>
>> If I've installed postgres on my system and it works for all of the utilities on my system that use postgres, but I've got a new version of postgres that's pre-release and I want to develop a new asterisk feature simultaneously that leverages that new functionality in postgres, I should be able to.
>>
>> Otherwise, if we do what you propose, then I'd have to wait until the new version of postgres was released as the standard version for (say) Fedora or Ubuntu, install that... and then develop for it.  Which could take months.
> That is not at all what I proposed. When you make inflammatory,
> over-the-top statements based on a misinterpretation of the answers to
> your questions, it does not make people want to continue helping you...
> and you have exhibited a pattern of doing just this.

So what I've written above is inflammatory and over-the-top?  Huh.

> 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.