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

[Philip Prindeville]

  On 7/31/10 7:00 AM, Leif Madsen wrote:
> On 7/30/2010 1:09 AM, Philip Prindeville wrote:
>>     On 7/29/10 4:34 PM, Leif Madsen wrote:
>>>      On 7/29/2010 5:56 PM, Philip Prindeville wrote:
>>>>       On 7/29/10 1:57 PM, Kevin P. Fleming wrote:
>>>>> 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.
>>> Actually I took that to mean that the pg-config tool should be modified,
>>> and not Asterisk.
>>>
>> Kevin was on the right track, that would be a solution... but it's not going to happen any time soon.
> I don't see time to resolve an issue as the reason not to fix it correctly.
>
>> A very similar "libtool is broken when cross-compiling" bug was filed over a year ago, and it has yet to be assigned or even verified.
> I can't find this issue anywhere on the bug tracker. Can you be more
> pedantic please?

Really?  I thought most people thought that I was usually too pedantic to start with.

Ok, well, you asked for it...


Seriously though, I'm saying I filed a bug upstream with the Gnu tools maintainers and it hasn't been fixed, over a year later.

Tilghman was suggesting that what's upstream needs to be fixed, and my answer was that past performance has indicated that this is unlikely to happen in a timely fashion... indeed the jury is still out about whether it will ever happen.

So working around tool deficiencies isn't completely off the table.


>> While Kevin's solution may be technically accurate, it's unlikely.
>>
>> At least not in anything resembling a workable timeframe.
> Again, I don't see the length of time as the reason not to fix this
> correctly.

How about the fact that it's out of our control?


>> So moving on, what's the workaround we're going to go with?
> I'm going to say the workaround is going to be the solution you develop
> or some other community developer develops in the meantime until the
> particular issue you're speaking of makes it up high enough on the
> priority list to be resolved by someone else.
>
> Leif Madsen.
>

And that's where we have an impasse, because whatever I typically come up with, Tilghman will hate as a kneejerk reaction... so spending the time to investigate the problem, develop a solution, test it, and submit it ends up being a waste of time.

Since only he seems to know how he'd like to fix it...