Thread: Installation location of DLLs

Installation location of DLLs

From
Peter Eisentraut
Date:
I see that Cygwin installs all the DLLs into /usr/bin, maybe we should do
that too?  (not /usr/bin, but ${bindir})

--
Peter Eisentraut   peter_e@gmx.net


Re: Installation location of DLLs

From
Jason Tishler
Date:
Peter,

On Fri, Sep 06, 2002 at 11:59:09PM +0200, Peter Eisentraut wrote:
> I see that Cygwin installs all the DLLs into /usr/bin, maybe we should
> do that too?  (not /usr/bin, but ${bindir})

Deja vu?...

I actually recommended this (via a patch) in the past, but it was vetoed
by you. :,)  I have been post-processing "make install" ever since.  I
would be very happy if you would reconsider this position.

The following are how my Cygwin PostgreSQL tarballs package DLLs:

    usr/bin/ecpg.dll
    usr/bin/pgeasy.dll
    usr/bin/pq++.dll
    usr/bin/pq.dll
    usr/lib/postgresql/plperl.dll
    usr/lib/postgresql/plpgsql.dll
    usr/lib/postgresql/plpython.dll
    usr/lib/perl5/site_perl/5.6.1/cygwin-multi/auto/Pg/Pg.dll
    usr/lib/python2.2/site-packages/_pgmodule.dll

Specifically, I recommend installing DLLs in ${bindir} that are linked
against via their import libraries -- for example, pq.dll.  In this way,
users do not need to add nonstandard components to their PATH.  On the
other hand, DLLs that are dlopen()'d should still be installed under
${libdir} -- for example, plpgsql.dll.

FYI, the above recommendation is exactly how "make install" works for
Cygwin Python.

Thanks,
Jason

Re: Installation location of DLLs

From
Peter Eisentraut
Date:
Jason Tishler writes:

> I actually recommended this (via a patch) in the past, but it was vetoed
> by you. :,)  I have been post-processing "make install" ever since.  I
> would be very happy if you would reconsider this position.

I remember.  I'm not saying that I like this very much, but if there's
reputable precedent we might as well go along with it.  OTOH, we currently
don't have a clean way to distinguish between imported and dlopen'able
DLLs in the build system, so I'm not sure how to implement this cleanly.

--
Peter Eisentraut   peter_e@gmx.net


service start script

From
Michael Adler
Date:
In order to reliably start up the postmaster, I have been using a script
to wrap around the postmaster binary and clean up some files that might
otherwise prevent the postmaster from starting.

The script looks something like this:

#!/usr/bin/bash
PGDATA=/usr/local/pgsql/data
rm -f $PGDATA/postmaster.pid
rm -f /tmp/.s.PGSQL.5432.lock /tmp/.s.PGSQL.5432
exec /bin/postmaster

This improved reliability 8 months ago.

Does anyone else use/need something like this? Or do the newer versions
simply work better without this functionality?

Mike Adler


Re: service start script

From
"Myles Bogner, Ph.D."
Date:
Michael,

    Your technique is very similar to what we do to ensure the
postmaster starts every time.  We install ours as an Windows service.

    Myles


Michael Adler wrote:

>In order to reliably start up the postmaster, I have been using a script
>to wrap around the postmaster binary and clean up some files that might
>otherwise prevent the postmaster from starting.
>
>The script looks something like this:
>
>#!/usr/bin/bash
>PGDATA=/usr/local/pgsql/data
>rm -f $PGDATA/postmaster.pid
>rm -f /tmp/.s.PGSQL.5432.lock /tmp/.s.PGSQL.5432
>exec /bin/postmaster
>
>This improved reliability 8 months ago.
>
>Does anyone else use/need something like this? Or do the newer versions
>simply work better without this functionality?
>
>Mike Adler
>
>
>---------------------------(end of broadcast)---------------------------
>TIP 6: Have you searched our list archives?
>
>http://archives.postgresql.org
>
>
>



Re: service start script

From
Brian Marshall
Date:
 I personally use my application binary to start the postmaster, that way
 I can check for the existance of the postmaster window before deleting
 any files, and I can also start the postmaster as a console app attached
 to the main dialog (or document view), and hide/unhide it as I please.I
 also create the pg_hba.conf/etc files at run-time, and delete them once
 the postmaster has started, in order to create a little bit more
 security. Has anyone else run into the problem of having the backend run
 in an untrusted environment on win9x machines (ie. no user protections
 on the file system)? I've managed to whittle the install down to the
 point where it's barely usable by anything but my app, but I can't
 prevent someone from taking the data home, modifying it, and bringing it
 back the next day...or re-installing the whole cygwin environment and
 having a field day...any suggestions on locking it down?

    -Brian Marshall

 PS: No, I don't have the option of running the PCs on W2K etc, or having
 a seperate unix box for the back end ^_^;

 >
 > In order to reliably start up the postmaster, I have been using a script
 > to wrap around the postmaster binary and clean up some files that might
 > otherwise prevent the postmaster from starting.
 >
 > The script looks something like this:
 >
 > #!/usr/bin/bash
 > PGDATA=/usr/local/pgsql/data
 > rm -f $PGDATA/postmaster.pid
 > rm -f /tmp/.s.PGSQL.5432.lock /tmp/.s.PGSQL.5432
 > exec /bin/postmaster
 >
 > This improved reliability 8 months ago.
 >
 > Does anyone else use/need something like this? Or do the newer versions
 > simply work better without this functionality?
 >
 > Mike Adler
 >
 >
 > ---------------------------(end of broadcast)---------------------------
 > TIP 6: Have you searched our list archives?
 >
 > http://archives.postgresql.org
 >




Why ? (couple questions about cygwin realibility)

From
Buyung Pamungkas
Date:
There's my couple questions about cygwin realibility.

1. pg_hba.conf didn't work on cygwin ?

I have installed cygwin 1.3.1 and postgresql 7.2.1.
Then I set my pg_hba.conf just for accept
db-connection from my computer.

But, another computer in my local subnet can access
those db either from application or another shell.

Why it happened on cygwin ? I had no problem when
installing postgresql on linux.

2. Makefile didn't work properly on cygwin ?

I have installed cygwin 1.3.1 and make version 3.79.1.
Then, I do to make some file. I had no problem when
running on linux. But, those make command have a
problem that can't process package directory or import
from my own directory on Java code.

Why it happened on cygwin+make+javac ?
I had no problem when compiling my Java program
one-by-one or make those files on linux.

3. /.bashrc didn't execute when I have started my
cygwin.

Many own setting that I had set on /.bashrc didn't
executed by cygwin. Why those happened ? Might I type
"source /.bashrc" everytime I used my cygwin ?



__________________________________________________
Yahoo! - We Remember
9-11: A tribute to the more than 3,000 lives lost
http://dir.remember.yahoo.com/tribute

Re: Installation location of DLLs

From
Jason Tishler
Date:
Peter,

[Sorry for the sluggish response time, but I just returned from
vacation...]

On Mon, Sep 09, 2002 at 08:39:17PM +0200, Peter Eisentraut wrote:
> Jason Tishler writes:
> > I actually recommended this (via a patch) in the past, but it was
> > vetoed by you. :,)  I have been post-processing "make install" ever
> > since.  I would be very happy if you would reconsider this position.
>
> I remember.  I'm not saying that I like this very much, but if there's
> reputable precedent we might as well go along with it.

I'm not sure whether this qualifies as a "reputable precedent," but
AFAICT most (if not all) Cygwin packages following this recommendation.

> OTOH, we currently don't have a clean way to distinguish between
> imported and dlopen'able DLLs in the build system, so I'm not sure how
> to implement this cleanly.

You would probably know the cleanest way.  However if you wish, I will
try to dig up my old patch.

Thanks,
Jason

Re: service start script

From
Jason Tishler
Date:
Michael,

Sorry for the sluggish response time, but I just returned from
vacation...]

On Tue, Sep 10, 2002 at 10:57:36AM -0400, Michael Adler wrote:
> Does anyone else use/need something like this?

I don't, but I don't (unfortunately) use PostgreSQL seriously anymore...

> Or do the newer versions simply work better without this
> functionality?

No, nothing has changed.

As per my README, I run postmaster as an NT service via cygrunsrv:

    cygrunsrv ...  --termsig INT --shutdown
                   ^^^^^^^^^^^^^ ^^^^^^^^^^

The above helps to ensure a clean shutdown when the NT box is shutdown.

I personally would *not* want PostgreSQL to automatically start back up
after an "unclean" shutdown.

Jason

Re: Why ? (couple questions about cygwin realibility)

From
Jason Tishler
Date:
Buyung,

On Wed, Sep 11, 2002 at 12:04:08PM -0700, Buyung Pamungkas wrote:
> There's my couple questions about cygwin realibility.
>
> 1. pg_hba.conf didn't work on cygwin ?

I haven't tried recently, but it worked for me the same as under Linux.
Is your pg_hba.conf in text mode (i.e., CRNL line endings)?  If so, then
convert it to binary mode (i.e., NL line endings).

> I have installed cygwin 1.3.1 and postgresql 7.2.1.
                          ^^^^^
Is the above a typo?  If not, then you are using a *very* old Cygwin
version.

> 2. Makefile didn't work properly on cygwin ?

Again, works for me.

> Why it happened on cygwin+make+javac ?

How about some specifics like error messages?  Did you install ant?

> 3. /.bashrc didn't execute when I have started my
> cygwin.
>
> Many own setting that I had set on /.bashrc didn't
> executed by cygwin. Why those happened ? Might I type
> "source /.bashrc" everytime I used my cygwin ?

The above is not a Cygwin PostgreSQL issue -- it's not even a Cygwin
one.  It is a generic bash issue and the solution is to use the
"--login" option.

Jason