Thread: 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.000000000 +0200 --- src/Makefile.port 2009-08-27 10:56:46.000000000 +0200 *************** *** 11,16 **** endif %.so: %.o ! $(CC) -shared -o $@ $< sqlmansect = 7 --- 11,16 ---- endif %.so: %.o ! $(CC) $(CFLAGS) -shared -o $@ $< sqlmansect = 7
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.000000000 +0200 > --- src/Makefile.port 2009-08-27 10:56:46.000000000 +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
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-bugs@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.old 2009-08-27 10:56:46.000000000 +0200
>> --- src/Makefile.port 2009-08-27 10:56:46.000000000 +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/
--On 27. August 2009 11:34:29 +0200 Boszormenyi Zoltan <zb@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
Heikki Linnakangas <heikki.linnakangas@enterprisedb.com> writes:
>> *** src/Makefile.port.old 2009-08-27 10:56:46.000000000 +0200
>> --- src/Makefile.port 2009-08-27 10:56:46.000000000 +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