Обсуждение: Re: build from Source: 9.0.1 / 9.1-alpha1 cannot build modules
Tom,
Turns out the make problem was actually one of my issuing 'make'. IE, the resolution was simply issuing 'gmake' explicitly. To add some special sauce to the recipe, the 'make' of the core server went without a hitch; was only the build of modules which did not work.... Kinda misleading.
Back in openSolaris days, by whatever PATH Black Magic, my habitual 'make' commands were actually getting to gnu make. Not so in default current builds of OpenIndiana. This may be of some use to someone.
Lou Picciano
From: "Tom Lane" <tgl@sss.pgh.pa.us>
To: "Lou Picciano" <loupicciano@comcast.net>
Cc: "pgsql-testers" <pgsql-testers@postgresql.org>, "pgsql-admin" <pgsql-admin@postgresql.org>
Sent: Sunday, October 10, 2010 12:53:26 PM
Subject: Re: [ADMIN] build from Source: 9.0.1 / 9.1-alpha1 cannot build modules
Lou Picciano <loupicciano@comcast.net> writes:
> 'Wacko', indeed, no?
> It's make 3.81, as packaged with OpenIndiana. gcc is 3.4.3.
Hm, 3.81 is a pretty popular version, so that doesn't seem to be the
answer. Did you look at exactly what was on the complained-of line?
It looks to me like it should be
top_srcdir = $(top_builddir)
which seems unobjectionable. But maybe there's something wrong
with your copy of Makefile.global.in.
BTW, was this a vpath build, or not?
regards, tom lane
--
Sent via pgsql-admin mailing list (pgsql-admin@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-admin
Lou Picciano <loupicciano@comcast.net> writes:
> Turns out the make problem was actually one of my issuing 'make'. IE, the resolution was simply issuing 'gmake'
explicitly.To add some special sauce to the recipe, the 'make' of the core server went without a hitch; was only the
buildof modules which did not work.... Kinda misleading.
That is interesting. What exactly is plain "make" invoking? In the
past, people trying to use non-GNU make have not gotten anywhere near
getting through a whole build --- and we've certainly not removed any
of our gmake-isms. It seems like you must have something that's sort
of 89% gmake, but not quite all the way there.
regards, tom lane
Hi Everybody, My environment: Windows 2008 32 bit Postgres 9.0 I have two unrelated questions: 1. Permissions: When I create a login role with superuser privileges in pgAdminIII I have the option of indicating that the superuser willalso have the permission to: "can modify catalog directly", when I look at the sql that is generated by that gui, I donot see a corresponding sql permission, I see: "CREATE ROLE kasia LOGIN ENCRYPTED PASSWORD 'md5ff0508b7bb33909c096d1b447a17d09b' SUPERUSER VALID UNTIL 'infinity';" A. What does "can modify catalog directly" actually do? I looked it up and I found : "This option determines whether therole can modify system catalog directly or not." But that really does not tell me much. B. Why is there no sql level equivalent? When I revoke the "can modify catalog directly" permission I get the followingsql: UPDATE pg_authid SET rolcatupdate=false WHERE OID=17331::oid; 2. Postgres client dlls on windows I am trying to identify the dlls that are considered postgres client libraries In 8.3.8 and 8.4.1 they were: Libpq.dll, comerr32.dll, gssapi32.dll, k5sprt32.dll, libeay32.dll, libiconv2.dll, libintl3.dll, ssleay32.dll In 9.0 they seem to be: Libpq.dll, ssleay32.dll, libeay32.dll, libintl-8.dll - IS THIS CORRECT? - Looking at the libpq dependencies the rest seem to be windows os dll Thank you, Sincerely, Kasia
Hi, Le 12/10/2010 19:25, Kasia Tuszynska a écrit : > [...] > 1. Permissions: > When I create a login role with superuser privileges in pgAdminIII I have the option of indicating that the superuser willalso have the permission to: "can modify catalog directly", when I look at the sql that is generated by that gui, I donot see a corresponding sql permission, I see: > "CREATE ROLE kasia LOGIN ENCRYPTED PASSWORD 'md5ff0508b7bb33909c096d1b447a17d09b' > SUPERUSER VALID UNTIL 'infinity';" > A. What does "can modify catalog directly" actually do? I looked it up and I found : "This option determines whetherthe role can modify system catalog directly or not." But that really does not tell me much. Yeah, we kinda suck at documenting things :) It refers to the rolcatupdate column in the pg_authid system table. Which is a permission to update the system catalogs (system tables). > B. Why is there no sql level equivalent? When I revoke the "can modify catalog directly" permission I get the followingsql: UPDATE pg_authid SET rolcatupdate=false WHERE OID=17331::oid; You create a superuser, which already has this capacity. So we don't need to add something else. Of course, if you uncheck it, we'll have to update the system table to set it to false. -- Guillaume http://www.postgresql.fr http://dalibo.com
Hi Guillaume, Thanks for your reply I did a bit more testing with the superuser priv issue, and now I came to the conclusion that pgAdminIIImay be doing something silly. I created a user: bob In pgAdminIII I checked off the box for: can inherit from parent role, can create db object, superuser Got the following sql: CREATE ROLE bob LOGIN ENCRYPTED PASSWORD 'md51e9484aace238e7cb2609130fd87646e' SUPERUSER INHERIT CREATEDB NOCREATEROLE; UPDATE pg_authid SET rolcapupdate=false WHERE rolname='bob'; Than I created bobb In pgAdminIII I checked off the box for: can inherit from parent role, can create db object, superuser, Can modify catalogdirectly Got the following sql: CREATE ROLE bobb LOGIN ENCRYPTED PASSWORD 'md51e9484aace238e7cb2609130fd87646e' SUPERUSER INHERIT CREATEDB NOCREATEROLE; Conclusion: Sql level superuser = pgAdminIII superuser + can modify catalog directly This is misleading, I would call it a pgAdminIII bug but who knows maybe it is a feature... Sincerely, Kasia -----Original Message----- From: Guillaume Lelarge [mailto:guillaume@lelarge.info] Sent: Tuesday, October 12, 2010 10:59 AM To: Kasia Tuszynska Cc: pgsql-admin Subject: Re: [ADMIN] two questions about pg 9.0 Hi, Le 12/10/2010 19:25, Kasia Tuszynska a écrit : > [...] > 1. Permissions: > When I create a login role with superuser privileges in pgAdminIII I have the option of indicating that the superuser willalso have the permission to: "can modify catalog directly", when I look at the sql that is generated by that gui, I donot see a corresponding sql permission, I see: > "CREATE ROLE kasia LOGIN ENCRYPTED PASSWORD 'md5ff0508b7bb33909c096d1b447a17d09b' > SUPERUSER VALID UNTIL 'infinity';" > A. What does "can modify catalog directly" actually do? I looked it up and I found : "This option determines whetherthe role can modify system catalog directly or not." But that really does not tell me much. Yeah, we kinda suck at documenting things :) It refers to the rolcatupdate column in the pg_authid system table. Which is a permission to update the system catalogs (system tables). > B. Why is there no sql level equivalent? When I revoke the "can modify catalog directly" permission I get the followingsql: UPDATE pg_authid SET rolcatupdate=false WHERE OID=17331::oid; You create a superuser, which already has this capacity. So we don't need to add something else. Of course, if you uncheck it, we'll have to update the system table to set it to false. -- Guillaume http://www.postgresql.fr http://dalibo.com
Hi Kasia, Le 13/10/2010 22:21, Kasia Tuszynska a écrit : > [...] > Thanks for your reply I did a bit more testing with the superuser priv issue, and now I came to the conclusion that pgAdminIIImay be doing something silly. > Sure, that happens more than I would like. > I created a user: bob > > In pgAdminIII I checked off the box for: can inherit from parent role, can create db object, superuser > Got the following sql: > CREATE ROLE bob LOGIN > ENCRYPTED PASSWORD 'md51e9484aace238e7cb2609130fd87646e' > SUPERUSER INHERIT CREATEDB NOCREATEROLE; > UPDATE pg_authid SET rolcapupdate=false WHERE rolname='bob'; > > Than I created bobb > In pgAdminIII I checked off the box for: can inherit from parent role, can create db object, superuser, Can modify catalogdirectly > Got the following sql: > CREATE ROLE bobb LOGIN > ENCRYPTED PASSWORD 'md51e9484aace238e7cb2609130fd87646e' > SUPERUSER INHERIT CREATEDB NOCREATEROLE; > > Conclusion: > Sql level superuser = pgAdminIII superuser + can modify catalog directly > > This is misleading, I would call it a pgAdminIII bug but who knows maybe it is a feature... > I would not call it a feature. I find this misleading too. I'm too tired right now to work on a fix, but it'll be easy and quick to do. I have a few things to commit tomorrow. I'll try to work on this at the same time. Thanks for your inputs. -- Guillaume http://www.postgresql.fr http://dalibo.com
Le 13/10/2010 23:20, Guillaume Lelarge a écrit : > Hi Kasia, > > Le 13/10/2010 22:21, Kasia Tuszynska a écrit : >> [...] >> Thanks for your reply I did a bit more testing with the superuser priv issue, and now I came to the conclusion that pgAdminIIImay be doing something silly. >> > > Sure, that happens more than I would like. > >> I created a user: bob >> >> In pgAdminIII I checked off the box for: can inherit from parent role, can create db object, superuser >> Got the following sql: >> CREATE ROLE bob LOGIN >> ENCRYPTED PASSWORD 'md51e9484aace238e7cb2609130fd87646e' >> SUPERUSER INHERIT CREATEDB NOCREATEROLE; >> UPDATE pg_authid SET rolcapupdate=false WHERE rolname='bob'; >> >> Than I created bobb >> In pgAdminIII I checked off the box for: can inherit from parent role, can create db object, superuser, Can modify catalogdirectly >> Got the following sql: >> CREATE ROLE bobb LOGIN >> ENCRYPTED PASSWORD 'md51e9484aace238e7cb2609130fd87646e' >> SUPERUSER INHERIT CREATEDB NOCREATEROLE; >> >> Conclusion: >> Sql level superuser = pgAdminIII superuser + can modify catalog directly >> >> This is misleading, I would call it a pgAdminIII bug but who knows maybe it is a feature... >> > > I would not call it a feature. I find this misleading too. I'm too tired > right now to work on a fix, but it'll be easy and quick to do. > > I have a few things to commit tomorrow. I'll try to work on this at the > same time. > I commited a fix. It should be available when 1.12.2 will be released. -- Guillaume http://www.postgresql.fr http://dalibo.com