Thread: Regression - GNUmakefile - pg_usleep
Attached patch fixes the SHLIB_LINK to add pgport now that pg_usleep is
added.
This is needed for AIX to resolve symbols at compile time.
This is also to be used in conjuction with the other patch I have
pending for Makefile.aix to SHLIB_LINK instead of LIBS to compile shared
objects.
Thanks,
-rocco
Attachment
"Rocco Altier" <RoccoA@Routescape.com> writes:
> Attached patch fixes the SHLIB_LINK to add pgport now that pg_usleep is
> added.
It seems highly unlikely that this will accomplish anything, given that
SHLIB_LINK is not used to construct regress.so.
> This is needed for AIX to resolve symbols at compile time.
I'm still wondering why that platform has such a hard time finding
symbols that are in the backend.
Probably a better fix is to make the new do_sleep function use
plain old sleep() instead of pg_usleep().
regards, tom lane
> -----Original Message-----
> From: pgsql-patches-owner@postgresql.org
> [mailto:pgsql-patches-owner@postgresql.org] On Behalf Of Tom Lane
> Sent: Sunday, July 24, 2005 10:47 AM
> To: Rocco Altier
> Cc: Patches (PostgreSQL)
> Subject: Re: [PATCHES] Regression - GNUmakefile - pg_usleep
>
>
> "Rocco Altier" <RoccoA@Routescape.com> writes:
> > Attached patch fixes the SHLIB_LINK to add pgport now that
> pg_usleep is
> > added.
>
> It seems highly unlikely that this will accomplish anything,
> given that
> SHLIB_LINK is not used to construct regress.so.
>
I have another patch in queue for this.
> > This is needed for AIX to resolve symbols at compile time.
>
> I'm still wondering why that platform has such a hard time finding
> symbols that are in the backend.
>
Right now there are 2 different sets of linker rules. One for a single
file -> .so (from Makefile.aix), and another for multiple files ->
lib<files>.so (from Makefile.shlib).
The patch I proposed to Makefile.shlib to pull all $LIBS in was rejected
since this would cause libpq to link against backend libraries, etc.
The suggested solution was to only pull in libraries as needed (which is
what is happening here, since pgport would be required).
I think the 2 sets of link rules should be more similar, since the
contrib moudules should get the same link option, instead of based on
how many files need to be linked together, thus Makefile.aix should be
changed to use SHLIB_LINK.
I am attaching all the patches for so for AIX to let it get past Contrib
on the buildfarm.
Makefile.aix.patch - will bring Makefile.aix in line with Makefile.shlib
by using SHLIB_LINK
contrib.libs.patch - will pull in the needed libraries for contrib
modules
regress.pgport.patch - same idea as contrib patch, pull in the needed
library
I hope this makes it a bit clearer what I am trying to achieve by having
all the pieces together in one place.
Thanks,
-rocco
PS. I am starting to look at using the facilities in AIX to support run
time linked libraries instead of at compile time. This does require AIX
4.2+, so I will try to leave the 4.1 code in place.
This time I actually have the patches :-)
-rocco
> -----Original Message-----
> From: pgsql-patches-owner@postgresql.org
> [mailto:pgsql-patches-owner@postgresql.org] On Behalf Of Rocco Altier
> Sent: Sunday, July 24, 2005 1:15 PM
> To: Tom Lane
> Cc: Patches (PostgreSQL)
> Subject: Re: [PATCHES] Regression - GNUmakefile - pg_usleep
>
>
>
>
> > -----Original Message-----
> > From: pgsql-patches-owner@postgresql.org
> > [mailto:pgsql-patches-owner@postgresql.org] On Behalf Of Tom Lane
> > Sent: Sunday, July 24, 2005 10:47 AM
> > To: Rocco Altier
> > Cc: Patches (PostgreSQL)
> > Subject: Re: [PATCHES] Regression - GNUmakefile - pg_usleep
> >
> >
> > "Rocco Altier" <RoccoA@Routescape.com> writes:
> > > Attached patch fixes the SHLIB_LINK to add pgport now that
> > pg_usleep is
> > > added.
> >
> > It seems highly unlikely that this will accomplish anything,
> > given that
> > SHLIB_LINK is not used to construct regress.so.
> >
> I have another patch in queue for this.
>
> > > This is needed for AIX to resolve symbols at compile time.
> >
> > I'm still wondering why that platform has such a hard time finding
> > symbols that are in the backend.
> >
> Right now there are 2 different sets of linker rules. One
> for a single
> file -> .so (from Makefile.aix), and another for multiple files ->
> lib<files>.so (from Makefile.shlib).
>
> The patch I proposed to Makefile.shlib to pull all $LIBS in
> was rejected
> since this would cause libpq to link against backend libraries, etc.
> The suggested solution was to only pull in libraries as
> needed (which is
> what is happening here, since pgport would be required).
>
> I think the 2 sets of link rules should be more similar, since the
> contrib moudules should get the same link option, instead of based on
> how many files need to be linked together, thus Makefile.aix should be
> changed to use SHLIB_LINK.
>
> I am attaching all the patches for so for AIX to let it get
> past Contrib
> on the buildfarm.
>
> Makefile.aix.patch - will bring Makefile.aix in line with
> Makefile.shlib
> by using SHLIB_LINK
> contrib.libs.patch - will pull in the needed libraries for contrib
> modules
> regress.pgport.patch - same idea as contrib patch, pull in the needed
> library
>
> I hope this makes it a bit clearer what I am trying to
> achieve by having
> all the pieces together in one place.
>
> Thanks,
> -rocco
>
> PS. I am starting to look at using the facilities in AIX to
> support run
> time linked libraries instead of at compile time. This does
> require AIX
> 4.2+, so I will try to leave the 4.1 code in place.
>
> ---------------------------(end of
> broadcast)---------------------------
> TIP 1: if posting/reading through Usenet, please send an appropriate
> subscribe-nomail command to majordomo@postgresql.org
> so that your
> message can get through to the mailing list cleanly
>
Attachment
"Rocco Altier" <RoccoA@Routescape.com> writes:
>> It seems highly unlikely that this will accomplish anything,
>> given that SHLIB_LINK is not used to construct regress.so.
>>
> I have another patch in queue for this.
Oh, I see, you want to use SHLIB_LINK in the %$(DLSUFFIX): %.o
rule.
> Right now there are 2 different sets of linker rules. One for a single
> file -> .so (from Makefile.aix), and another for multiple files ->
> lib<files>.so (from Makefile.shlib).
Actually, that's not the reason it's like this, at all. The
percent-rules in the per-platform Makefiles are a hangover from long
before we had Makefile.shlib, and most of them pretty well suck.
As noted in Makefile.hpux,
# Rule for building shared libs (currently used only for regression test
# shlib ... should go away, since this is not really enough knowledge)
As far as I can see, src/test/regress/GNUmakefile is the only place
still depending on those rules. I've wanted for quite some time to
change the regression makefile to use Makefile.shlib to build
regress.so, whereupon we could get rid of the percent-rules in the
per-platform Makefiles entirely. Maybe it's time to have a go at that.
regards, tom lane
"Rocco Altier" <RoccoA@Routescape.com> writes:
> This time I actually have the patches :-)
I've applied the parts of this that add -lm to contrib modules, but not
the parts that add -lpgport. That's because libpgport is not built to
be relocatable, and so including it fails hard on platforms that care:
/usr/ccs/bin/ld +h libtsearch2.sl.0 -b +b /home/postgres/testversion/lib dict_ex.o dict.o snmap.o stopword.o common.o
prs_dcfg.odict_snowball.o dict_ispell.o dict_syn.o wparser.o wparser_def.o ts_cfg.o tsvector.o rewrite.o crc32.o
query.ogistidx.o tsvector_op.o rank.o ts_stat.o snowball/SUBSYS.o ispell/SUBSYS.o wordparser/SUBSYS.o -L../../src/port
-L/usr/local/lib-lpgport -lm `gcc -L../../src/port -Wl,-z -Wl,+b -Wl,/home/postgres/testversion/lib
-print-libgcc-file-name` -o libtsearch2.sl.0
/usr/ccs/bin/ld: DP relative code in file ../../src/port/libpgport.a(exec.o) - shared library must be position
independent. Use +z or +Z to recompile.
make: *** [libtsearch2.sl.0] Error 1
We will need to either eliminate the dependencies on libpgport, or
use the extra-compilation technique used in, eg, libpq.
regards, tom lane
I see what you are saying now. libpgport is not a shared library -
because of AIX's funny linking, I had not noticed that before.
You propose making it similar to libpq. By that do you mean breaking it
into 2 separate diretories - backend/libpq & interfaces/libpq - so that
we create the libraries pgport and pgport_srv from different directories
- possibly using the existing backend/port and port?
If you mean something else, let me know so that I might persue that
path.
In the mean time, an AIX specific patch(hack) would be to shove -lpgport
into BE_DLLLIB in Makefile.aix - patch attached.
Thanks
-rocco (desperate to get AIX green on buildfarm)
> -----Original Message-----
> From: Tom Lane [mailto:tgl@sss.pgh.pa.us]
> Sent: Sunday, July 24, 2005 7:34 PM
> To: Rocco Altier
> Cc: Patches (PostgreSQL)
> Subject: Re: [PATCHES] Regression - GNUmakefile - pg_usleep
>
>
> "Rocco Altier" <RoccoA@Routescape.com> writes:
> > This time I actually have the patches :-)
>
> I've applied the parts of this that add -lm to contrib
> modules, but not
> the parts that add -lpgport. That's because libpgport is not built to
> be relocatable, and so including it fails hard on platforms that care:
>
> /usr/ccs/bin/ld +h libtsearch2.sl.0 -b +b
> /home/postgres/testversion/lib dict_ex.o dict.o snmap.o
> stopword.o common.o prs_dcfg.o dict_snowball.o dict_ispell.o
> dict_syn.o wparser.o wparser_def.o ts_cfg.o tsvector.o
> rewrite.o crc32.o query.o gistidx.o tsvector_op.o rank.o
> ts_stat.o snowball/SUBSYS.o ispell/SUBSYS.o
> wordparser/SUBSYS.o -L../../src/port -L/usr/local/lib
> -lpgport -lm `gcc -L../../src/port -Wl,-z -Wl,+b
> -Wl,/home/postgres/testversion/lib -print-libgcc-file-name`
> -o libtsearch2.sl.0
> /usr/ccs/bin/ld: DP relative code in file
> ../../src/port/libpgport.a(exec.o) - shared library must be position
> independent. Use +z or +Z to recompile.
> make: *** [libtsearch2.sl.0] Error 1
>
> We will need to either eliminate the dependencies on libpgport, or
> use the extra-compilation technique used in, eg, libpq.
>
> regards, tom lane
>
"Rocco Altier" <RoccoA@Routescape.com> writes:
> You propose making it similar to libpq. By that do you mean breaking it
> into 2 separate diretories - backend/libpq & interfaces/libpq - so that
> we create the libraries pgport and pgport_srv from different directories
> - possibly using the existing backend/port and port?
No, I'm talking about just importing the individual source files that
are needed and compiling them with -fpic enabled as part of the module
that needs them. Look at what libpq does with pgstrcasecmp.c, or what
I just made the regression test module do with pgsleep.c.
regards, tom lane