Re: Build system problem in 8.3.x
От | Boszormenyi Zoltan |
---|---|
Тема | Re: Build system problem in 8.3.x |
Дата | |
Msg-id | 4A966C25.7080209@cybertec.at обсуждение исходный текст |
Ответ на | Re: Build system problem in 8.3.x (Heikki Linnakangas <heikki.linnakangas@enterprisedb.com>) |
Список | 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/
В списке pgsql-hackers по дате отправления: