Re: BUG #14033: cross-compilation to ARM fails

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Andres Freund <andres(at)anarazel(dot)de>
Cc: Christoph Berg <myon(at)debian(dot)org>, Alvaro Herrera <alvherre(at)2ndquadrant(dot)com>, Daniel Golle <daniel(at)makrotopia(dot)org>, pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #14033: cross-compilation to ARM fails
Date: 2016-04-15 13:57:59
Message-ID: 6344.1460728679@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

Andres Freund <andres(at)anarazel(dot)de> writes:
> On 2016-04-15 00:08:02 -0400, Tom Lane wrote:
>> I can't see us taking either of those answers. We haven't been willing
>> to accept a hard dependency on perl at build time, why would we do so
>> at run time?

> We could build pg_config both on the host and build architectures
> (presumably with the typical triplet as a prefix). Not sure how to
> automatically use that in pg_config --pgxs invocations in extension
> makefiles though.

Could we insist that for a cross-compilation, the appropriate instance
of pg_config has to be found first in the PATH under the name pg_config?
That turns it into a matter of preparing the build environment.

A different line of thought is to expose the data as data rather than
an executable. For example, as a makefile fragment containing variable
assignments, which would be include'd by extension makefiles. There
are a lot of problems to be solved with this idea too, of course:
what do you do to make it play in non-make-based build systems? And
where would this file live? The lack of a PATH mechanism makes it
far harder for would-be users to find the file. Still, maybe we could
make something out of that approach.

regards, tom lane

In response to

Responses

Browse pgsql-bugs by date

  From Date Subject
Next Message Christoph Berg 2016-04-15 15:01:12 Re: BUG #14033: cross-compilation to ARM fails
Previous Message Andres Freund 2016-04-15 04:13:14 Re: BUG #14033: cross-compilation to ARM fails