Thread: Re: AIX compilation problems (was Re: Proposal ...)

Re: AIX compilation problems (was Re: Proposal ...)

From
"Zeugswetter Andreas SB SD"
Date:
> > 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


Re: AIX compilation problems (was Re: Proposal ...)

From
Peter Eisentraut
Date:
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



Re: AIX compilation problems (was Re: Proposal ...)

From
"Zeugswetter Andreas SB SD"
Date:
> > 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


Re: AIX compilation problems (was Re: Proposal ...)

From
"Zeugswetter Andreas SB SD"
Date:
> > 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


Re: AIX compilation problems (was Re: Proposal ...)

From
Tom Lane
Date:
"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


Re: AIX compilation problems (was Re: Proposal ...)

From
"Zeugswetter Andreas SB SD"
Date:
> > 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


Re: AIX compilation problems (was Re: Proposal ...)

From
Peter Eisentraut
Date:
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



Re: AIX compilation problems (was Re: Proposal ...)

From
Peter Eisentraut
Date:
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



Re: AIX compilation problems (was Re: Proposal ...)

From
Peter Eisentraut
Date:
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