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