Обсуждение: Lessons learned on how to build 7.0.2 on AIX 4.x

Поиск
Список
Период
Сортировка

Lessons learned on how to build 7.0.2 on AIX 4.x

От
rsand@vgalleries.com (Richard Sand)
Дата:
Hi all-  I've recently had to suffer a torturous process of building 7.0.2 on AIX 4.3.2.  From my pouring through other newsgroups I've concluded that the problems I've hit exist at least on AIX 4.1.5 and 4.3.3 as well.  This note describes the problems I've encountered and how to get around them, as well as a request for some fixes.  Please accept my apology if this is known information- I couldn't find anything in this digest here.
 
1) First of all, you can't use IBM's make utility, gotta use GNU make.  So download gmake from http://www-frec.bull.com/docs/download.htm (where its put into an AIX installp package).  Be sure to rename /usr/local/bin/make to /usr/local/bin/gmake so as not to confuse it with AIX's make.
 
2) Now, when you first download postgres and try to run the configure program, if you are using GCC instead of the AIX compiler (which is expensive), you have to use the command:
 
./configure --with-template=aix_gcc

This forces GCC.  I used GCC 2.95.2. 
 
2a) If you need to install GCC there are some AIX packages you need.  I installed GCC and typed "gcc" and it responded "No input files found".  Sounds good.  But when I tried the configure command again it still fails to find a compiler.  So I write a little test program and try to compile it and it gives me an error "installation problem, cannot exec `as'".  Well, as it turns out, AIX doesn't install the assembler by default, you have to go and install the package "bos.adt.tools".  That's a wonderful IBM brainchild. :)  Ok, that's that mystery solved.
 
2b) Next, it gave me errors looking for a c++ compiler, so be sure to download gcc.g++.2.95.2 which installs AFTER gcc.2.95.2.
 
2c) Well, then I try compiling my test program with g++ and it complains about finding libm.a, so now we have to install the package "bos.adt.libm".  So dumb. :)
 
3) Ok so we're finally ready to build, and as soon as I type 'gmake', I get this error: 
 
Making postgres.imp
 ./backend/port/aix/mkldexport.sh postgres /usr/local/bin > postgres.imp nm: postgres: 0654-200 Cannot open the specified file.
 nm: A file or directory in the path name does not exist.
 
This is apparently a bug in the make scripts for Postgres.  I did find a workaround which was documented in one of the newsgroups.  I went into the ./src/backend directory and did 'gmake', and even though it failed I then copied the ./src/backend/postgres.imp file to ./src, and that seemed to correct the problem.
 
4) So I continue my gmake'ing, and this time it fails badly trying to compile libpq++.so.  The same person that suggested the postgres.imp workaround also said that they couldn't get the c++ portion to compile, so I hand edited the Makefile.global file in ./src and commented out the line "HAVE_Cplusplus=true"
 
This, finally, at long last (and after all the trouble of installing G++ and libm!), got the rest of Postgres 7.0.2 to compile.
 
Oh, and as the make output scrolled by, I see that it failed as well building some plpsql stuff, but it was non fatal.  There were also a zillion warnings, many of them about multiple type declarations for int8, int32, etc.

Now on to the installation (which I haven't done yet)!!
 
I hope this information is helpful to any of you building this on AIX, and hopefully we can have someone from the Postgres team revisit the AIX installation process!  The missing AIX packages stuff could be added to the FAQ_AIX file, and hopefully the error in the makefile and the problem linking libpq++.so can be fixed.  If the latter is a G++ problem (would not surprise me!), keep in mind that many of us AIX users don't use xlC because IBM licenses the damned thing, so GCC is more more economical!
 
Best regards,
 

Re: Lessons learned on how to build 7.0.2 on AIX 4.x

От
rsand@vgalleries.com (Richard Sand)
Дата:
>> 1) First of all, you can't use IBM's make utility, gotta use GNU make.
>
>Quoth the installation instructions:
>
>"Building PostgreSQL requires GNU make. It will not work with other make
>programs."

Yes I was just making sure all of the AIX instructions were combined. :)

>> you have to use the command:
>>
>> ./configure --with-template=aix_gcc
>
>That has got to be a bug. The configure script should look for gcc
>first. Can you show the relevant lines of configure output (checking for
>cc... etc), when you don't use that option?

It hung up on line 1226.  I just tested this again and can confirm, it will
not find gcc unless I explicitly use this switch.  The output from
config.log is:

configure:1102: checking for gcc
configure:1215: checking whether the C compiler
(xlc -qmaxmem=16384 -qhalt=w -qs
rcmsg -qlanglvl=extended -qlonglong ) works
configure:1231: xlc -o
conftest -qmaxmem=16384 -qhalt=w -qsrcmsg -qlanglvl=exten
ded -qlonglong   conftest.c  1>&5
./configure[1230]: xlc:  not found
configure: failed program was:

#line 1226 "configure"
#include "confdefs.h"

main(){return(0);}

>> Making postgres.imp
>>  ./backend/port/aix/mkldexport.sh postgres /usr/local/bin > postgres.imp
nm: postgres: 0654-200 Cannot open the specified file.
>>  nm: A file or directory in the path name does not exist.
>>
>> This is apparently a bug in the make scripts for Postgres.
>
>Can you describe how to fix it? The AIX shared library stuff is an enigma
>to me.

Well, all I did was do gmake in another directory (./src/backend) and then I
copy the postgres.imp file from that directory back to ./src, and then the
make can continue OK.  So its got to be a simple bug in the makefile for
./src that works when you build postgres.imp in another directory.  I don't
know my way around makefiles except for the very basics, so I'm sorry I
can't help more... I'll run more tests if you'd like, let me know what you'd
like to see.

>
>> I hand edited the Makefile.global file in ./src and commented out the
>> line "HAVE_Cplusplus=true"
>
>Quoth configure --help:
>
>"  --without-CXX           prevent building C++ code"

Ah, you are wise. :)  Yes, that switch is better.  BUT, since I do have g++
installed and working, why can't the C++ code be built in the first place?

>
>
>> Oh, and as the make output scrolled by, I see that it failed as well
>> building some plpsql stuff, but it was non fatal.
>
>If it failed then it was fatal, and vice versa. Please elaborate.

Here is an excerpt from stdout/err when I do a gmake all from ./src.  You'll
notice that it starts to build plpgsql and then dies, but the make
continues.  I don't know if this is vital (the procedure stuff?)- I haven't
tried actually doing anything with Postgres yet but I do have postmaster
running, I created a database, and I can connect to it.  Of course, the
regression test failed because I don't have plpgsql!  Anyway, here's the
except:

gmake[2]: Entering directory `/usr/src/postgresql-7.0.2/src/pl/plpgsql'
gmake -C src all
gmake[3]: Entering directory `/usr/src/postgresql-7.0.2/src/pl/plpgsql/src'
../../../backend/port/aix/mkldexport.sh libplpgsql.a /usr/local/pgsql/lib >
libp
lpgsql.exp
ld -H512 -bM:SRE -bI:../../../backend/postgres.imp -bE:libplpgsql.exp -o
libplpg
sql.so libplpgsql.a -lPW -lcrypt -lld -lnsl -ldl -lm -lcurses  -lc
ld: 0711-327 WARNING: Entry point not found: __start
ld: 0711-317 ERROR: Undefined symbol: CurrentMemoryContext
ld: 0711-317 ERROR: Undefined symbol: .MemoryContextAlloc
ld: 0711-317 ERROR: Undefined symbol: .MemoryContextFree
ld: 0711-317 ERROR: Undefined symbol: .MemoryContextRealloc
ld: 0711-317 ERROR: Undefined symbol: .elog
ld: 0711-317 ERROR: Undefined symbol: .SearchSysCacheTuple
ld: 0711-317 ERROR: Undefined symbol: .textout
ld: 0711-317 ERROR: Undefined symbol: .nameout
ld: 0711-317 ERROR: Undefined symbol: .fmgr_info
ld: 0711-317 ERROR: Undefined symbol: .int2in
ld: 0711-317 ERROR: Undefined symbol: .SPI_connect
ld: 0711-317 ERROR: Undefined symbol: CurrentTriggerData
ld: 0711-317 ERROR: Undefined symbol: .SPI_finish
ld: 0711-317 ERROR: Undefined symbol: Warn_restart
ld: 0711-317 ERROR: Undefined symbol: .SPI_palloc
ld: 0711-317 ERROR: Undefined symbol: .textin
ld: 0711-317 ERROR: Undefined symbol: .namein
ld: 0711-317 ERROR: Undefined symbol: .get_temp_rel_by_physicalname
ld: 0711-317 ERROR: Undefined symbol: .SPI_gettypeid
ld: 0711-317 ERROR: Undefined symbol: .SPI_copytuple
ld: 0711-317 ERROR: Undefined symbol: SPI_processed
ld: 0711-317 ERROR: Undefined symbol: SPI_tuptable
ld: 0711-317 ERROR: Undefined symbol: fmgr_pl_finfo
ld: 0711-317 ERROR: Undefined symbol: .SPI_fnumber
ld: 0711-317 ERROR: Undefined symbol: .SPI_getvalue
ld: 0711-317 ERROR: Undefined symbol: .SPI_prepare
ld: 0711-317 ERROR: Undefined symbol: .SPI_saveplan
ld: 0711-317 ERROR: Undefined symbol: .SPI_getbinval
ld: 0711-317 ERROR: Undefined symbol: .SPI_execp
ld: 0711-317 ERROR: Undefined symbol: .heap_formtuple
ld: 0711-317 ERROR: Undefined symbol: .newNode
ld: 0711-317 ERROR: Undefined symbol: .SPI_push
ld: 0711-317 ERROR: Undefined symbol: .ExecEvalExpr
ld: 0711-317 ERROR: Undefined symbol: .SPI_pop
ld: 0711-317 ERROR: Undefined symbol: .length
ld: 0711-345 Use the -bloadmap or -bnoquiet option to obtain more
information.
gmake[3]: *** [libplpgsql.so] Error 8
gmake[3]: Leaving directory `/usr/src/postgresql-7.0.2/src/pl/plpgsql/src'
gmake[2]: [all] Error 2 (ignored)
gmake[2]: Leaving directory `/usr/src/postgresql-7.0.2/src/pl/plpgsql'
gmake[1]: Leaving directory `/usr/src/postgresql-7.0.2/src/pl'
All of PostgreSQL is successfully made. Ready to install.

I hope this helps!

-Richard



Re: Lessons learned on how to build 7.0.2 on AIX 4.x

От
Peter Eisentraut
Дата:
Richard Sand writes:

> >> ./configure --with-template=aix_gcc

> It hung up on line 1226.  I just tested this again and can confirm, it will
> not find gcc unless I explicitly use this switch.

I see. The template matching logic preempts the choice of compiler. We'll
need to ponder a fix for that.

> >> Making postgres.imp
> >>  ./backend/port/aix/mkldexport.sh postgres /usr/local/bin > postgres.imp
> nm: postgres: 0654-200 Cannot open the specified file.
> >>  nm: A file or directory in the path name does not exist.

> So its got to be a simple bug in the makefile for ./src that works
> when you build postgres.imp in another directory.

Let's see: The rule that invokes this is

src/backend/Makefile:

all: postgres $(POSTGRES_IMP) ...

The commands are in src/makefiles/Makefile.aix:

$(POSTGRES_IMP):       @echo Making $@       $(MKLDEXPORT) postgres $(BINDIR) > $@       $(CC)
-Wl,-bE:$(SRCDIR)/backend/$@-o postgres $(OBJS) ../utils/version.o $(LDFLAGS)
 

Now the error message seems to imply that it can't find the `postgres'
executable, but the postgres executable should exist before this rule
runs. Now you seems to be saying that you have to moving postgres.imp to
the src/ directory corrected this problem, but sorry, this doesn't make
sense to me. :-( You could maybe help rebuilding completely from scratch
and showing the complete make output so we can see what is being invoked
in what order.


> BUT, since I do have g++ installed and working, why can't the C++ code
> be built in the first place?

C++ is so wonderfully incompatible to itself, and the libpq++ interface is
not used so much that few people bother fixing it. Be our guest.


> gmake[2]: Entering directory `/usr/src/postgresql-7.0.2/src/pl/plpgsql'
> gmake -C src all
> gmake[3]: Entering directory `/usr/src/postgresql-7.0.2/src/pl/plpgsql/src'
> ../../../backend/port/aix/mkldexport.sh libplpgsql.a /usr/local/pgsql/lib >
> libp
> lpgsql.exp
> ld -H512 -bM:SRE -bI:../../../backend/postgres.imp -bE:libplpgsql.exp -o
> libplpg
> sql.so libplpgsql.a -lPW -lcrypt -lld -lnsl -ldl -lm -lcurses  -lc
> ld: 0711-327 WARNING: Entry point not found: __start
> ld: 0711-317 ERROR: Undefined symbol: CurrentMemoryContext
> ld: 0711-317 ERROR: Undefined symbol: .MemoryContextAlloc
> ld: 0711-317 ERROR: Undefined symbol: .MemoryContextFree
[more of that]

Well, yes, these symbols are undefined within plpgsql. They are supposed
to be resolved when you load plpgsql into the server at runtime. Now I am
venturing a guess here that this postgres.imp file is supposed to contain
a list of symbols that are defined by the postmaster and that the
dynamically loadable modules such as plpgsql should not worry about, but
as we saw, this file is not being created correctly. (Perhaps you should
try to move it back to src/backend for the purposes of building plpgsql.
That would at least give it a chance of finding the file.)


-- 
Peter Eisentraut                  Sernanders väg 10:115
peter_e@gmx.net                   75262 Uppsala
http://yi.org/peter-e/            Sweden



RE: Lessons learned on how to build 7.0.2 on AIX 4.x

От
"Darren King"
Дата:
> > lpgsql.exp
> > ld -H512 -bM:SRE -bI:../../../backend/postgres.imp -bE:libplpgsql.exp -o
> > libplpg
> > sql.so libplpgsql.a -lPW -lcrypt -lld -lnsl -ldl -lm -lcurses  -lc
> > ld: 0711-327 WARNING: Entry point not found: __start
> > ld: 0711-317 ERROR: Undefined symbol: CurrentMemoryContext
> > ld: 0711-317 ERROR: Undefined symbol: .MemoryContextAlloc
> > ld: 0711-317 ERROR: Undefined symbol: .MemoryContextFree
> [more of that]
>
> Well, yes, these symbols are undefined within plpgsql. They are supposed
> to be resolved when you load plpgsql into the server at runtime. Now I am
> venturing a guess here that this postgres.imp file is supposed to contain
> a list of symbols that are defined by the postmaster and that the
> dynamically loadable modules such as plpgsql should not worry about, but
> as we saw, this file is not being created correctly. (Perhaps you should
> try to move it back to src/backend for the purposes of building plpgsql.
> That would at least give it a chance of finding the file.)

Exactly that...postgres.imp contains a list of symbols that are available
for modules to use to resolve in their code.

The script src/backend/port/aix/mkldexport.sh gathers the symbols from
postgres.o.  Then that list is given to the linker via -bE when making the
executable to allow those symbols to be used by external modules.  When
compiling the other modules, the linker needs to get that file with -bI to
tell it that any unresolved symbols that are in postgres.imp will be in the
postgres exectable.

Did you get it to compile without munging the order of the #includes?  On my
4.1.5 system, postgres.h has to the first #include file.  Seems there are
two different prototypes for getopt in the aix system includes.  If unistd.h
or math.h are included *before* postgres.h, the bogus prototype is
encountered first.  There's also a function somewhere in libpq that has an
unsigned char parameter that is at odds with the -qchars=signed flag in the
aix compile.

These are really only problems because I put in -qhalt=w to cause the
compile to treat warnings as errors and stop the compile.  I believe Andreas
wanted to turn this off a while back, but I had always found it useful and
rather cool that a project as large as postgres could compile without any
warnings whatsoever.

darrenk