Re: AIX compilation problems (was Re: [HACKERS] Proposal ...)
Patch applied. Thanks. --- Zeugswetter Andreas SB SD wrote: > > > > > > 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. > > > > 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. > > Attached is a patch to fix the mb linking problems on AIX. As a nice side effect > it reduces the duplicate symbol warnings to linking libpq.so and libecpg.so > (all shlibs that are not postmaster loadable modules). > > Please apply to current (only affects AIX). > > The _LARGE_FILES problem is unfortunately still open, unless Peter > has fixed it per his recent idea. > > Thanx > Andreas Content-Description: mb_link_patch4.gz [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: AIX compilation problems (was Re: [HACKERS] Proposal ...)
Still in queue. I will apply today. --- Samuel A Horwitz wrote: > Has this fix been applied to the cvs yet, I am still getting the same > error > > > On Tue, 1 Oct 2002, Zeugswetter Andreas SB SD wrote: > > > Date: Tue, 1 Oct 2002 10:23:13 +0200 > > From: Zeugswetter Andreas SB SD <[EMAIL PROTECTED]> > > To: Peter Eisentraut <[EMAIL PROTECTED]> > > Cc: PostgreSQL Development <[EMAIL PROTECTED]> > > Subject: Re: AIX compilation problems (was Re: [HACKERS] Proposal ...) > > > > > > > > Attached is a patch to fix the mb linking problems on AIX. As a nice side >effect > > > > it reduces the duplicate symbol warnings to linking libpq.so and libecpg.so > > > > (all shlibs that are not postmaster loadable modules). > > > > > > Can you explain the method behind your patch? Have you tried -bnogc? > > > > -bnogc would (probably) have been the correct switch reading the man page, > > but the method was previously not good since it involved the following: > > > > 1. create a static postgres executable from the SUBSYS.o's > > 2. create an exports file from above > > 3. recreate a shared postgres executable > > > > This naturally had a cyclic dependency, that could not properly be > > reflected in the Makefile (thus a second make sometimes left you with > > a static postgres unless you manually removed postgres.imp). > > > > Now it does: > > postgres.imp: $(OBJS) > > create a temporary SUBSYS.o from all $(OBJS) > > create a postgres.imp from SUBSYS.o > > rm temporary SUBSYS.o > > > > postgres: postgres.imp > > link a shared postgres > > > > A second change was to move the import and export files to the end of the link >line, > > then the linker knows not to throw a duplicate symbol warning, and keeps all >symbols > > that are mentioned in the exports file (== -bnogc restricted to $(OBJS) symbols). > > > > Thus now only libpq.so and libecpg.so still show the duplicate symbol warnings >since their > > link line should actually not include postgres.imp . I did not see how to make a >difference > > between loadable modules (need postgres.imp) and interface libraries (do not need >postgres.imp), > > but since the resulting libs are ok, I left it at that. > > > > I tested both gcc and xlc including regression tests. > > > > Andreas > > > > ---(end of broadcast)--- > > TIP 3: if posting/reading through Usenet, please send an appropriate > > subscribe-nomail command to [EMAIL PROTECTED] so that your > > message can get through to the mailing list cleanly > > > > > [EMAIL PROTECTED] (Samuel A Horwitz) > > > > ---(end of broadcast)--- > TIP 6: Have you searched our list archives? > > http://archives.postgresql.org > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: AIX compilation problems (was Re: [HACKERS] Proposal ...)
Has this fix been applied to the cvs yet, I am still getting the same error On Tue, 1 Oct 2002, Zeugswetter Andreas SB SD wrote: > Date: Tue, 1 Oct 2002 10:23:13 +0200 > From: Zeugswetter Andreas SB SD <[EMAIL PROTECTED]> > To: Peter Eisentraut <[EMAIL PROTECTED]> > Cc: PostgreSQL Development <[EMAIL PROTECTED]> > Subject: Re: AIX compilation problems (was Re: [HACKERS] Proposal ...) > > > > > Attached is a patch to fix the mb linking problems on AIX. As a nice side effect > > > it reduces the duplicate symbol warnings to linking libpq.so and libecpg.so > > > (all shlibs that are not postmaster loadable modules). > > > > Can you explain the method behind your patch? Have you tried -bnogc? > > -bnogc would (probably) have been the correct switch reading the man page, > but the method was previously not good since it involved the following: > > 1. create a static postgres executable from the SUBSYS.o's > 2. create an exports file from above > 3. recreate a shared postgres executable > > This naturally had a cyclic dependency, that could not properly be > reflected in the Makefile (thus a second make sometimes left you with > a static postgres unless you manually removed postgres.imp). > > Now it does: > postgres.imp: $(OBJS) > create a temporary SUBSYS.o from all $(OBJS) > create a postgres.imp from SUBSYS.o > rm temporary SUBSYS.o > > postgres: postgres.imp > link a shared postgres > > A second change was to move the import and export files to the end of the link line, > then the linker knows not to throw a duplicate symbol warning, and keeps all symbols > that are mentioned in the exports file (== -bnogc restricted to $(OBJS) symbols). > > Thus now only libpq.so and libecpg.so still show the duplicate symbol warnings since >their > link line should actually not include postgres.imp . I did not see how to make a >difference > between loadable modules (need postgres.imp) and interface libraries (do not need >postgres.imp), > but since the resulting libs are ok, I left it at that. > > I tested both gcc and xlc including regression tests. > > Andreas > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly > [EMAIL PROTECTED] (Samuel A Horwitz) ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: AIX compilation problems (was Re: [HACKERS] Proposal ...)
Your patch has been added to the PostgreSQL unapplied patches list at: http://candle.pha.pa.us/cgi-bin/pgpatches I will try to apply it within the next 48 hours. --- Zeugswetter Andreas SB SD wrote: > > > > > > 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. > > > > 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. > > Attached is a patch to fix the mb linking problems on AIX. As a nice side effect > it reduces the duplicate symbol warnings to linking libpq.so and libecpg.so > (all shlibs that are not postmaster loadable modules). > > Please apply to current (only affects AIX). > > The _LARGE_FILES problem is unfortunately still open, unless Peter > has fixed it per his recent idea. > > Thanx > Andreas Content-Description: mb_link_patch4.gz [ Attachment, skipping... ] > > ---(end of broadcast)--- > TIP 2: you can get off all lists at once with the unregister command > (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED]) -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: AIX compilation problems (was Re: [HACKERS] Proposal ...)
Samuel A Horwitz wrote: > has this patched been applied to the CVS yet? No, I was waiting to see if there were any negative comments, but seeing none, I will add it to the patch queue today. --- > > > On Tue, 1 Oct 2002, Zeugswetter > Andreas SB SD wrote: > > > Date: Tue, 1 Oct 2002 10:23:13 +0200 > > From: Zeugswetter Andreas SB SD <[EMAIL PROTECTED]> > > To: Peter Eisentraut <[EMAIL PROTECTED]> > > Cc: PostgreSQL Development <[EMAIL PROTECTED]> > > Subject: Re: AIX compilation problems (was Re: [HACKERS] Proposal ...) > > > > > > > > Attached is a patch to fix the mb linking problems on AIX. As a nice side >effect > > > > it reduces the duplicate symbol warnings to linking libpq.so and libecpg.so > > > > (all shlibs that are not postmaster loadable modules). > > > > > > Can you explain the method behind your patch? Have you tried -bnogc? > > > > -bnogc would (probably) have been the correct switch reading the man page, > > but the method was previously not good since it involved the following: > > > > 1. create a static postgres executable from the SUBSYS.o's > > 2. create an exports file from above > > 3. recreate a shared postgres executable > > > > This naturally had a cyclic dependency, that could not properly be > > reflected in the Makefile (thus a second make sometimes left you with > > a static postgres unless you manually removed postgres.imp). > > > > Now it does: > > postgres.imp: $(OBJS) > > create a temporary SUBSYS.o from all $(OBJS) > > create a postgres.imp from SUBSYS.o > > rm temporary SUBSYS.o > > > > postgres: postgres.imp > > link a shared postgres > > > > A second change was to move the import and export files to the end of the link >line, > > then the linker knows not to throw a duplicate symbol warning, and keeps all >symbols > > that are mentioned in the exports file (== -bnogc restricted to $(OBJS) symbols). > > > > Thus now only libpq.so and libecpg.so still show the duplicate symbol warnings >since their > > link line should actually not include postgres.imp . I did not see how to make a >difference > > between loadable modules (need postgres.imp) and interface libraries (do not need >postgres.imp), > > but since the resulting libs are ok, I left it at that. > > > > I tested both gcc and xlc including regression tests. > > > > Andreas > > > > ---(end of broadcast)--- > > TIP 3: if posting/reading through Usenet, please send an appropriate > > subscribe-nomail command to [EMAIL PROTECTED] so that your > > message can get through to the mailing list cleanly > > > > > [EMAIL PROTECTED] (Samuel A Horwitz) > > > > ---(end of broadcast)--- > TIP 5: Have you checked our extensive FAQ? > > http://www.postgresql.org/users-lounge/docs/faq.html > -- Bruce Momjian| http://candle.pha.pa.us [EMAIL PROTECTED] | (610) 359-1001 + If your life is a hard drive, | 13 Roberts Road + Christ can be your backup.| Newtown Square, Pennsylvania 19073 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: AIX compilation problems (was Re: [HACKERS] Proposal ...)
has this patched been applied to the CVS yet? On Tue, 1 Oct 2002, Zeugswetter Andreas SB SD wrote: > Date: Tue, 1 Oct 2002 10:23:13 +0200 > From: Zeugswetter Andreas SB SD <[EMAIL PROTECTED]> > To: Peter Eisentraut <[EMAIL PROTECTED]> > Cc: PostgreSQL Development <[EMAIL PROTECTED]> > Subject: Re: AIX compilation problems (was Re: [HACKERS] Proposal ...) > > > > > Attached is a patch to fix the mb linking problems on AIX. As a nice side effect > > > it reduces the duplicate symbol warnings to linking libpq.so and libecpg.so > > > (all shlibs that are not postmaster loadable modules). > > > > Can you explain the method behind your patch? Have you tried -bnogc? > > -bnogc would (probably) have been the correct switch reading the man page, > but the method was previously not good since it involved the following: > > 1. create a static postgres executable from the SUBSYS.o's > 2. create an exports file from above > 3. recreate a shared postgres executable > > This naturally had a cyclic dependency, that could not properly be > reflected in the Makefile (thus a second make sometimes left you with > a static postgres unless you manually removed postgres.imp). > > Now it does: > postgres.imp: $(OBJS) > create a temporary SUBSYS.o from all $(OBJS) > create a postgres.imp from SUBSYS.o > rm temporary SUBSYS.o > > postgres: postgres.imp > link a shared postgres > > A second change was to move the import and export files to the end of the link line, > then the linker knows not to throw a duplicate symbol warning, and keeps all symbols > that are mentioned in the exports file (== -bnogc restricted to $(OBJS) symbols). > > Thus now only libpq.so and libecpg.so still show the duplicate symbol warnings since >their > link line should actually not include postgres.imp . I did not see how to make a >difference > between loadable modules (need postgres.imp) and interface libraries (do not need >postgres.imp), > but since the resulting libs are ok, I left it at that. > > I tested both gcc and xlc including regression tests. > > Andreas > > ---(end of broadcast)--- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to [EMAIL PROTECTED] so that your > message can get through to the mailing list cleanly > [EMAIL PROTECTED] (Samuel A Horwitz) ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: AIX compilation problems (was Re: [HACKERS] Proposal ...)
> > > Attached is a patch to fix the mb linking problems on AIX. As a nice side effect > > > it reduces the duplicate symbol warnings to linking libpq.so and libecpg.so > > > (all shlibs that are not postmaster loadable modules). > > > > Can you explain the method behind your patch? Have you tried -bnogc? > > -bnogc would (probably) have been the correct switch reading > the man page, > but the method was previously not good since it involved the > following: > > 1. create a static postgres executable from the SUBSYS.o's > 2. create an exports file from above > 3. recreate a shared postgres executable > > This naturally had a cyclic dependency, that could not properly be > reflected in the Makefile (thus a second make sometimes left you with > a static postgres unless you manually removed postgres.imp). > > Now it does: > postgres.imp: $(OBJS) > create a temporary SUBSYS.o from all $(OBJS) > create a postgres.imp from SUBSYS.o > rm temporary SUBSYS.o > > postgres: postgres.imp > link a shared postgres > > A second change was to move the import and export files to > the end of the link line, > then the linker knows not to throw a duplicate symbol > warning, and keeps all symbols > that are mentioned in the exports file (== -bnogc restricted > to $(OBJS) symbols). > > Thus now only libpq.so and libecpg.so still show the > duplicate symbol warnings since their > link line should actually not include postgres.imp . I did > not see how to make a difference > between loadable modules (need postgres.imp) and interface > libraries (do not need postgres.imp), > but since the resulting libs are ok, I left it at that. Note that this behavior did thus not change. > > I tested both gcc and xlc including regression tests. What happens with this now ? Thanx Andreas mb_link_patch4.gz Description: mb_link_patch4.gz ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: AIX compilation problems (was Re: [HACKERS] Proposal ...)
> > Attached is a patch to fix the mb linking problems on AIX. As a nice side effect > > it reduces the duplicate symbol warnings to linking libpq.so and libecpg.so > > (all shlibs that are not postmaster loadable modules). > > Can you explain the method behind your patch? Have you tried -bnogc? -bnogc would (probably) have been the correct switch reading the man page, but the method was previously not good since it involved the following: 1. create a static postgres executable from the SUBSYS.o's 2. create an exports file from above 3. recreate a shared postgres executable This naturally had a cyclic dependency, that could not properly be reflected in the Makefile (thus a second make sometimes left you with a static postgres unless you manually removed postgres.imp). Now it does: postgres.imp: $(OBJS) create a temporary SUBSYS.o from all $(OBJS) create a postgres.imp from SUBSYS.o rm temporary SUBSYS.o postgres: postgres.imp link a shared postgres A second change was to move the import and export files to the end of the link line, then the linker knows not to throw a duplicate symbol warning, and keeps all symbols that are mentioned in the exports file (== -bnogc restricted to $(OBJS) symbols). Thus now only libpq.so and libecpg.so still show the duplicate symbol warnings since their link line should actually not include postgres.imp . I did not see how to make a difference between loadable modules (need postgres.imp) and interface libraries (do not need postgres.imp), but since the resulting libs are ok, I left it at that. I tested both gcc and xlc including regression tests. Andreas ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: AIX compilation problems (was Re: [HACKERS] Proposal ...)
Zeugswetter Andreas SB SD writes: > Attached is a patch to fix the mb linking problems on AIX. As a nice side effect > it reduces the duplicate symbol warnings to linking libpq.so and libecpg.so > (all shlibs that are not postmaster loadable modules). Can you explain the method behind your patch? Have you tried -bnogc? -- Peter Eisentraut [EMAIL PROTECTED] ---(end of broadcast)--- TIP 5: Have you checked our extensive FAQ? http://www.postgresql.org/users-lounge/docs/faq.html
Re: AIX compilation problems (was Re: [HACKERS] Proposal ...)
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: AIX compilation problems (was Re: [HACKERS] Proposal ...)
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 4: Don't 'kill -9' the postmaster
Re: AIX compilation problems (was Re: [HACKERS] Proposal ...)
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: AIX compilation problems (was Re: [HACKERS] Proposal ...)
> > 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 ---(end of broadcast)--- TIP 6: Have you searched our list archives? http://archives.postgresql.org
Re: AIX compilation problems (was Re: [HACKERS] Proposal ...)
"Zeugswetter Andreas SB SD" <[EMAIL PROTECTED]> 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: AIX compilation problems (was Re: [HACKERS] Proposal ...)
> > 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 ---(end of broadcast)--- TIP 3: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: AIX compilation problems (was Re: [HACKERS] Proposal ...)
> > 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 ---(end of broadcast)--- TIP 1: subscribe and unsubscribe commands go to [EMAIL PROTECTED]
Re: AIX compilation problems (was Re: [HACKERS] Proposal ...)
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 [EMAIL PROTECTED] ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
Re: AIX compilation problems (was Re: [HACKERS] 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 ---(end of broadcast)--- TIP 2: you can get off all lists at once with the unregister command (send "unregister YourEmailAddressHere" to [EMAIL PROTECTED])
