Bug 177564 - The spec file install own version of pg_config.h which is missing support for Alpha
Summary: The spec file install own version of pg_config.h which is missing support for...
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: postgresql
Version: rawhide
Hardware: alpha
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Tom Lane
QA Contact: David Lawrence
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-01-11 20:30 UTC by Sergey Tikhonov
Modified: 2013-07-03 03:07 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2006-02-16 16:46:31 UTC
Type: ---
Embargoed:


Attachments (Terms of Use)

Description Sergey Tikhonov 2006-01-11 20:30:00 UTC
Description of problem:
The spec file install own version of pg_config.h which is missing support for
Alpha. Please apply the following small patch that fixes it:

--- pg_config.h.orig    2005-12-15 22:38:07.000000000 +0300
+++ pg_config.h 2006-01-11 23:22:46.000000000 +0300
@@ -21,4 +21,6 @@
 #include "pg_config_s390x.h"
 #elif defined(__s390__)
 #include "pg_config_s390.h"
+#elif defined(__alpha__)
+#include "pg_config_alpha.h"
 #endif

It would help AlphaCore project to build this package unmodified.
Thank you.

Version-Release number of selected component (if applicable):
8.1.2-1

Comment 1 Tom Lane 2006-01-11 21:21:07 UTC
Yeah, this whole concept of trying to avoid header variations with architecture
seems messed up :-(.  I wonder what other arches people are going to try to
build Fedora SRPMs on.

Note to self: mysql has same issue.

Comment 2 Sergey Tikhonov 2006-01-11 21:37:50 UTC
Yes, I don't see any advantage of it. We don't have different arch header files
in the same package. As far as I understand the pg_config.h is build by
configure for specific arch and won't be used on other arches.


Comment 3 Tom Lane 2006-01-11 22:21:27 UTC
The reason it's there is to allow installing both 32- and 64-bit devel RPMs on
multilib machines.  It's an ugly solution but I don't (yet?) see a better one.

Comment 4 Sergey Tikhonov 2006-01-12 20:15:53 UTC
I see. How about doing this only for multilib arches. For non-multilib arches
copy postgres "pg_include.h" as pg_include_original.h and include it as last
chance if none of defines worked. It would keep current approach, but give other
arches the chance to work. :)

Thank you.
 

Comment 5 Tom Lane 2006-01-12 22:02:47 UTC
That's a good thought.  Actually, on non-multilib machines there's no reason for
adding the indirection at all.  I'll see what I can do.

Comment 6 Tom Lane 2006-02-16 16:46:31 UTC
Fixed in postgresql-8.1.3-1


Note You need to log in before you can comment on or make changes to this bug.