[HACKERS] Build system problem in 8.3.x
Hi, we have come across a problem in 8.3.x (8.3.5 and 8.3.7 was tested) while building PostgreSQL for 32-bit on 64-bit RHEL5 and Fedora 9. The following defines were used before running configure: export CFLAGS=-m32 export LD=ld -melf_i386 The above are needed because when SUBSYS.o files are created, the $(LD) ... lines don't contain $(LDFLAGS) anywhere, so overriding $(LD) on the command line has to be done instead. However, there's one additional problem that can be solved by the attached one liner. The problem is that during building the core, something (test/regress) requires contrib/spi/refint.so to be built. The error follows: make -C ../../../contrib/spi refint.so autoinc.so make[3]: Entering directory `/home/zozo/Schönig-számlák/lucent/postgresql-8.3.5/contrib/spi' gcc -m32 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -fpic -DREFINT_VERBOSE -I. -I../../src/include -D_GNU_SOURCE -c -o refint.o refint.c gcc -shared -o refint.so refint.o /usr/bin/ld: i386 architecture of input file `refint.o' is incompatible with i386:x86-64 output I tried building contrib manually, but it turned out that the same error happens whenever contrib/*/Makefile contains MODULES instead of MODULE_big. I modified Makefile.port in the attached patch, and now all the contrib files also build correctly. Best regards, Zoltán Böszörményi -- Bible has answers for everything. Proof: But let your communication be, Yea, yea; Nay, nay: for whatsoever is more than these cometh of evil. (Matthew 5:37) - basics of digital technology. May your kingdom come - superficial description of plate tectonics -- Zoltán Böszörményi Cybertec Schönig Schönig GmbH http://www.postgresql.at/ *** src/Makefile.port.old 2009-08-27 10:56:46.0 +0200 --- src/Makefile.port 2009-08-27 10:56:46.0 +0200 *** *** 11,16 endif %.so: %.o ! $(CC) -shared -o $@ $ sqlmansect = 7 --- 11,16 endif %.so: %.o ! $(CC) $(CFLAGS) -shared -o $@ $ sqlmansect = 7 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Build system problem in 8.3.x
Boszormenyi Zoltan wrote: we have come across a problem in 8.3.x (8.3.5 and 8.3.7 was tested) while building PostgreSQL for 32-bit on 64-bit RHEL5 and Fedora 9. The following defines were used before running configure: export CFLAGS=-m32 export LD=ld -melf_i386 The above are needed because when SUBSYS.o files are created, the $(LD) ... lines don't contain $(LDFLAGS) anywhere, so overriding $(LD) on the command line has to be done instead. However, there's one additional problem that can be solved by the attached one liner. The problem is that during building the core, something (test/regress) requires contrib/spi/refint.so to be built. If you're willing to override $(LD), seems you could get around that additional problem by overriding $(CC) as well: export CC=$(CC) -m32 export LD=ld -melf_i386 *** src/Makefile.port.old 2009-08-27 10:56:46.0 +0200 --- src/Makefile.port 2009-08-27 10:56:46.0 +0200 *** *** 11,16 endif %.so: %.o ! $(CC) -shared -o $@ $ sqlmansect = 7 --- 11,16 endif %.so: %.o ! $(CC) $(CFLAGS) -shared -o $@ $ sqlmansect = 7 I guess we should change that rule to use $(LD) instead of $(CC), and include $(LDFLAGS) in the rules that build SUBSYS.o. Or maybe there's a reason they are what they are, I don't know. (SUBSYS.o's are gone in 8.4 anyway) -- Heikki Linnakangas EnterpriseDB http://www.enterprisedb.com -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Build system problem in 8.3.x
Heikki Linnakangas írta:
Boszormenyi Zoltan wrote:
we have come across a problem in 8.3.x (8.3.5 and 8.3.7 was tested)
while building PostgreSQL for 32-bit on 64-bit RHEL5 and Fedora 9.
The following defines were used before running configure:
export CFLAGS=-m32
export LD=ld -melf_i386
The above are needed because when SUBSYS.o files are created,
the $(LD) ... lines don't contain $(LDFLAGS) anywhere, so overriding
$(LD) on the command line has to be done instead.
However, there's one additional problem that can be solved by the
attached one liner. The problem is that during building the core,
something (test/regress) requires contrib/spi/refint.so to be built.
If you're willing to override $(LD), seems you could get around that
additional problem by overriding $(CC) as well:
export CC=$(CC) -m32
export LD=ld -melf_i386
Yes, it's true. Ultimately CFLAGS and LDFLAGS should be
the way to control special compilation or linking. But there's
a problem:
export CFLAGS=-m32
export LDFLAGS=-melf_i386
$ ./configure --prefix=/home/zozo/pgc835_32 --enable-depend --enable-debug
checking build system type... x86_64-unknown-linux-gnu
checking host system type... x86_64-unknown-linux-gnu
checking which template to use... linux
checking whether to build with 64-bit integer date/time support... no
checking whether NLS is wanted... no
checking for default port number... 5432
checking for gcc... gcc
checking for C compiler default output file name... configure: error: C
compiler cannot create executables
See `config.log' for more details.
In config.log:
configure:2246: checking for C compiler default output file name
configure:2249: gcc -m32 -melf_i386 conftest.c 5
cc1: error: unrecognized command line option -melf_i386
configure:2252: $? = 1
configure: failed program was:
| /* confdefs.h. */
|
| #define PACKAGE_NAME PostgreSQL
| #define PACKAGE_TARNAME postgresql
| #define PACKAGE_VERSION 8.3.5
| #define PACKAGE_STRING PostgreSQL 8.3.5
| #define PACKAGE_BUGREPORT pgsql-b...@postgresql.org
| #define PG_VERSION 8.3.5
| #define DEF_PGPORT 5432
| #define DEF_PGPORT_STR 5432
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:2291: error: C compiler cannot create executables
GCC should get only CFLAGS on the compilation line,
it passes -melf_i386 to LD automatically.
Also, modifying LD and CC may stir up some problems in the
USE_PGXS=1 machinery, I don't know. Adding $(LDFLAGS)
to Makefiles would be the way to go, some discussion is needed.
*** src/Makefile.port.old2009-08-27 10:56:46.0 +0200
--- src/Makefile.port2009-08-27 10:56:46.0 +0200
***
*** 11,16
endif
%.so: %.o
!$(CC) -shared -o $@ $
sqlmansect = 7
--- 11,16
endif
%.so: %.o
!$(CC) $(CFLAGS) -shared -o $@ $
sqlmansect = 7
I guess we should change that rule to use $(LD) instead of $(CC), and
include $(LDFLAGS) in the rules that build SUBSYS.o. Or maybe there's a
reason they are what they are, I don't know.
Maybe the one who wrote the Makefiles for this SUBSYS.o
scheme could tell us. Maybe the reason is simply multilib systems
weren't so widespread at the time.
(SUBSYS.o's are gone in 8.4 anyway)
I know, but older 8.x versions are still supported, such build-system
fixes might be allowed to go in...
--
Bible has answers for everything. Proof:
But let your communication be, Yea, yea; Nay, nay: for whatsoever is more
than these cometh of evil. (Matthew 5:37) - basics of digital technology.
May your kingdom come - superficial description of plate tectonics
--
Zoltán Böszörményi
Cybertec Schönig Schönig GmbH
http://www.postgresql.at/
--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Build system problem in 8.3.x
--On 27. August 2009 11:34:29 +0200 Boszormenyi Zoltan z...@cybertec.at wrote: make -C ../../../contrib/spi refint.so autoinc.so make[3]: Entering directory `/home/zozo/Schönig-számlák/lucent/postgresql-8.3.5/contrib/spi' gcc -m32 -Wall -Wmissing-prototypes -Wpointer-arith -Winline -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -fpic -DREFINT_VERBOSE -I. -I../../src/include -D_GNU_SOURCE -c -o refint.o refint.c gcc -shared -o refint.so refint.o /usr/bin/ld: i386 architecture of input file `refint.o' is incompatible with i386:x86-64 output I had a similar problem some time in the past on a multiarch SuSE on pSeries (however, it was the other way around, building 64-bit on 32-bit userspace). I blogged my solution here: http://psoos.blogspot.com/2008/05/building-postgresql-on-ibm-pseriessles.html -- Thanks Bernd -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Build system problem in 8.3.x
Heikki Linnakangas heikki.linnakan...@enterprisedb.com writes: *** src/Makefile.port.old2009-08-27 10:56:46.0 +0200 --- src/Makefile.port2009-08-27 10:56:46.0 +0200 *** *** 11,16 endif %.so: %.o !$(CC) -shared -o $@ $ sqlmansect = 7 --- 11,16 endif %.so: %.o !$(CC) $(CFLAGS) -shared -o $@ $ sqlmansect = 7 I guess we should change that rule to use $(LD) instead of $(CC), and include $(LDFLAGS) in the rules that build SUBSYS.o. Or maybe there's a reason they are what they are, I don't know. (SUBSYS.o's are gone in 8.4 anyway) Those rules are used to build .so's, not SUBSYS.o's. I see that this change is already applied to Makefile.linux in HEAD, but I'm not sure it's worth back-patching by itself. We know that on Darwin, which is where the most work has been done on cross-arch/multiarch builds, you really need the SUBSYS.o-ectomy as well to make multiarch builds simple. And we're *not* back-patching that. I'm inclined to say that making this workable is an 8.4 feature and you should use 8.4 if you need it. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
