Re: Build system problem in 8.3.x - Mailing list pgsql-hackers

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/