Обсуждение: Re: AIX compilation problems (was Re: Proposal ...)
> > PS: pg snapshot 09/11 does not compile on AIX (large files (don't want > > _LARGE_FILES), > > Please provide details. On AIX we would only want to make the large file api visible (_LARGE_FILE_API) which automatically gets defined when xlc is used with -qlonglong. #ifdef _LARGE_FILE_API extern off64_t lseek64(int, off64_t, int); #endif configure somehow thinks it needs to #define _LARGE_FILES though, which then clashes with pg_config.h's _LARGE_FILES. I think the test needs to #include unistd.h . > > and mb conversions (pg_ascii2mic and pg_mic2ascii not > > found in the postmaster and not included from elsewhere) shared libs on AIX need to be able to resolve all symbols at linkage time. Those two symbols are in backend/utils/SUBSYS.o but not in the postgres executable. My guess is, that they are eliminated by the linker ? Do they need an extern declaration ? Andreas
Zeugswetter Andreas SB SD writes: > configure somehow thinks it needs to #define _LARGE_FILES though, which > then clashes with pg_config.h's _LARGE_FILES. I think the test needs to > #include unistd.h . _LARGE_FILES is defined because it's necessary to make off_t 64 bits. If you disagree, please post compiler output. > > > and mb conversions (pg_ascii2mic and pg_mic2ascii not > > > found in the postmaster and not included from elsewhere) > > shared libs on AIX need to be able to resolve all symbols at linkage time. > Those two symbols are in backend/utils/SUBSYS.o but not in the postgres > executable. > My guess is, that they are eliminated by the linker ? Do they need an extern > declaration ? They are defined in backend/utils/mb/conv.c and declared in include/mb/pg_wchar.h. They're also linked into the postmaster. I don't see anything unusual. -- Peter Eisentraut peter_e@gmx.net
> > configure somehow thinks it needs to #define _LARGE_FILES though, which > > then clashes with pg_config.h's _LARGE_FILES. I think the test needs to > > #include unistd.h . > > _LARGE_FILES is defined because it's necessary to make off_t 64 bits. If > you disagree, please post compiler output. Ah, if we want off_t to be 64 bits, then we need _LARGE_FILES. The problem is, that scan.c includes unistd.h before postgres.h and thus unistd.h defines _LARGE_FILE_API which is not allowed together with _LARGE_FILES. Do you know an answer ? Offhand I can only think of using -D_LARGE_FILES as a compiler flag :-( Do we really want a general 64 bit off_t or would it be sufficient in the two places that use fseeko ? Andreas
> > shared libs on AIX need to be able to resolve all symbols at linkage time. > > Those two symbols are in backend/utils/SUBSYS.o but not in the postgres > > executable. > > My guess is, that they are eliminated by the linker ? Do they need an extern > > declaration ? Further research prooved, that the AIX linker eliminates functions on a per c file basis if none of them is referenced elsewhere (declared extern or not). Thus it eliminates the whole conv.c file from the postgres executable since those functions are only used by the conversion shared objects. Anybody have an idea what I can do ? Andreas
"Zeugswetter Andreas SB SD" <ZeugswetterA@spardat.at> writes:
> Further research prooved, that the AIX linker eliminates functions on a per
> c file basis if none of them is referenced elsewhere (declared extern or not).
> Thus it eliminates the whole conv.c file from the postgres executable since
> those functions are only used by the conversion shared objects.
Yipes. Surely there is a linker switch to suppress that behavior?
regards, tom lane
> > Further research prooved, that the AIX linker eliminates functions on a per > > c file basis if none of them is referenced elsewhere (declared extern or not). > > Thus it eliminates the whole conv.c file from the postgres executable since > > those functions are only used by the conversion shared objects. > > Yipes. Surely there is a linker switch to suppress that behavior? -brtl , but that does a lot more that we don't want and does not work :-( I think the best thing to do would be to do the following: link a postgres.so from all SUBSYS.o's create postgres.imp from postgres.so (since it is a lib it has all symbols) link postgres with postgres.imp and the SUBSYS.o's Currently it does link postgres create postgres.imp from postgres link postgres again using postgres.imp This is not so good anyways, since it would actually require a cyclic dependency. A remake currently requires to manually remove postgres and postgres.imp . Not sure how to do this in the Makefiles however :-( Should this be done in src/backend/Makefile with a if portname ? I don't like that. Can sombody help, please ? Andreas
Zeugswetter Andreas SB SD writes: > The problem is, that scan.c includes unistd.h before postgres.h > and thus unistd.h defines _LARGE_FILE_API which is not allowed > together with _LARGE_FILES. Do you know an answer ? > Offhand I can only think of using -D_LARGE_FILES as a compiler flag :-( That would be pretty tricky to arrange, since the macro that detects all this is bundled with Autoconf. Also, it would only fix one particular manifestation of the overall problem, namely that pg_config.h needs to come first, period. I can see two ways to fix this properly: 1. Change the flex call to something like (echo '#include "postgres.h"'; $(FLEX) -t -o$@) >$@ This would throw off all #line references by one. 2. Direct the flex output to another file, say scan2.c, and create a new scan.c like this: #include "postgres.h" #include "scan2.c" and create the object file from that. We have half a dozen flex calls in our tree, so either fix would propagate a great deal of ugliness around. > Do we really want a general 64 bit off_t or would it be sufficient in the > two places that use fseeko ? It affects all the I/O functions. If we want to access large files we need to use the large-file capable function interface. -- Peter Eisentraut peter_e@gmx.net
Zeugswetter Andreas SB SD writes: > -brtl , but that does a lot more that we don't want and does not work :-( I think -bnogc is the switch you want. -- Peter Eisentraut peter_e@gmx.net
Zeugswetter Andreas SB SD writes: > The problem is, that scan.c includes unistd.h before postgres.h > and thus unistd.h defines _LARGE_FILE_API which is not allowed > together with _LARGE_FILES. Do you know an answer ? Actually, a better idea I just had is to include scan.c at the end of gram.c and compile them both into one object file. -- Peter Eisentraut peter_e@gmx.net