Thread: Installation location of DLLs
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
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
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
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
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
>
>
>
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
>
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
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
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
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