Tom Lane wrote:
> Peter Eisentraut <[EMAIL PROTECTED]> writes:
> > If we determine the default data directory off the configure option
> > --localstatedir then we can simply use the same mechanisms that have
> > been discussed for determining all the other directories at run time
> > relative to
Bruce Momjian wrote:
Peter Eisentraut wrote:
Jan Wieck wrote:
> Boy, nobody was suggesting 100% static linking. What kind of madness
> are you getting into if you link libpq.a into psql? There is
> something between all or nothing, isn't there?
It's not going to be only psql and libpq. The next th
Peter Eisentraut wrote:
> Jan Wieck wrote:
> > Boy, nobody was suggesting 100% static linking. What kind of madness
> > are you getting into if you link libpq.a into psql? There is
> > something between all or nothing, isn't there?
>
> It's not going to be only psql and libpq. The next thing is,
Jan Wieck wrote:
> Boy, nobody was suggesting 100% static linking. What kind of madness
> are you getting into if you link libpq.a into psql? There is
> something between all or nothing, isn't there?
It's not going to be only psql and libpq. The next thing is, someone
wants to have a relocatable
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > Peter Eisentraut wrote:
> > > Bruce Momjian wrote:
> > > > We already have --disable-rpath. Seems we would just need
> > > > something to use the *.a files.
> > >
> > > I think it is perfectly sufficient to say that if you want a
> > > relocatable
Bruce Momjian wrote:
> Peter Eisentraut wrote:
> > Bruce Momjian wrote:
> > > We already have --disable-rpath. Seems we would just need
> > > something to use the *.a files.
> >
> > I think it is perfectly sufficient to say that if you want a
> > relocatable install, don't use rpath. Static linki
Bruce Momjian wrote:
Peter Eisentraut wrote:
Bruce Momjian wrote:
> We already have --disable-rpath. Seems we would just need something
> to use the *.a files.
I think it is perfectly sufficient to say that if you want a relocatable
install, don't use rpath. Static linking will lead to all other
Peter Eisentraut wrote:
Bruce Momjian wrote:
We already have --disable-rpath. Seems we would just need something
to use the *.a files.
I think it is perfectly sufficient to say that if you want a relocatable
install, don't use rpath. Static linking will lead to all other kinds
of madness.
Boy,
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > We already have --disable-rpath. Seems we would just need something
> > to use the *.a files.
>
> I think it is perfectly sufficient to say that if you want a relocatable
> install, don't use rpath. Static linking will lead to all other kinds
Peter Eisentraut wrote:
> Bruce Momjian wrote:
> > We already have --disable-rpath. Seems we would just need something
> > to use the *.a files.
>
> I think it is perfectly sufficient to say that if you want a relocatable
> install, don't use rpath. Static linking will lead to all other kinds
Bruce Momjian wrote:
> We already have --disable-rpath. Seems we would just need something
> to use the *.a files.
I think it is perfectly sufficient to say that if you want a relocatable
install, don't use rpath. Static linking will lead to all other kinds
of madness.
Also, some platforms of
Jan Wieck wrote:
If I remore the whole -rpath thing, and remove the two -L options and
the -lpq and -lpgport, and add the libpq.a and libpgport.a explicitly
to the linker call, the psql executable on my Linux box grows from
421761 to 677682 bytes in size. It is still shared linked against
libc,
Jan Wieck wrote:
> > Static linking of our binaries? Hmmm. Makes sense. We would need a
> > special flag for that. I can add it to the TODO.
> >
> > Seems my testing was flawed because I didn't clean out my hard-coded
> > directory properly. I see now:
> >
> > $ bin/initdb
> > bin/in
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Greg Stark wrote:
> > Jan Wieck <[EMAIL PROTECTED]> writes:
> >
> > > You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your
> > > environment disables setuid() for security reasons on some platforms. So one
> > > would have to
Bruce Momjian wrote:
Jan Wieck wrote:
Bruce Momjian wrote:
> Jan Wieck wrote:
>> > I think if we go for the plan outlined, we will not need a special
>> > configure flag. (People might decide to move the install dir long after
>> > they install it.) By default, everything sits under pgsql as pgsq
Greg Stark wrote:
Jan Wieck <[EMAIL PROTECTED]> writes:
You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your
environment disables setuid() for security reasons on some platforms. So one
would have to wrap every PG related program into equally named shell scripts or
aliase
Greg Stark wrote:
> Jan Wieck <[EMAIL PROTECTED]> writes:
>
> > You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your
> > environment disables setuid() for security reasons on some platforms. So one
> > would have to wrap every PG related program into equally named shell
Jan Wieck wrote:
> Bruce Momjian wrote:
> > Jan Wieck wrote:
> >> > I think if we go for the plan outlined, we will not need a special
> >> > configure flag. (People might decide to move the install dir long after
> >> > they install it.) By default, everything sits under pgsql as pgsql/bin,
> >>
Jan Wieck <[EMAIL PROTECTED]> writes:
> You know how much trouble that causes? The existance of LD_LIBRARY_PATH in your
> environment disables setuid() for security reasons on some platforms. So one
> would have to wrap every PG related program into equally named shell scripts or
> aliases to just
Bruce Momjian wrote:
Jan Wieck wrote:
> I think if we go for the plan outlined, we will not need a special
> configure flag. (People might decide to move the install dir long after
> they install it.) By default, everything sits under pgsql as pgsql/bin,
> pgsql/lib, etc. I can't see how making
Jan Wieck wrote:
> > I think if we go for the plan outlined, we will not need a special
> > configure flag. (People might decide to move the install dir long after
> > they install it.) By default, everything sits under pgsql as pgsql/bin,
> > pgsql/lib, etc. I can't see how making it relative i
Bruce Momjian wrote:
Andrew Dunstan wrote:
>I think we should use the relative-path method *unless* the configure
>command called out specific installation directories (that is, not
>just --prefix but --datadir and/or related options). If you use one of
>those then that absolute path should be use
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> If we determine the default data directory off the configure option
> --localstatedir then we can simply use the same mechanisms that have
> been discussed for determining all the other directories at run time
> relative to the binaries.
Agreed, we
Tom Lane wrote:
> The thing I like about the relative-path idea is that it actually
> improves and extends our existing ability to support multiple
> installs. I wonder whether we could even allow PGDATA to default
> to a relative path (../data)?
Doesn't work very well when you install into /usr/
Marc Slemko <[EMAIL PROTECTED]> writes:
> The downside to this is that it isn't as friendly for various
> command line tools that people run, since they then have to specify
> the path on the command line.
Exactly. Not only unfriendly, but quite error-prone, especially in
a multiple-install situa
Shachar Shemesh said:
> Bruce Momjian wrote:
>
>>Comments?
>>
>>
> What's wrong with the way it's done by everybody else?
>
> Have hardcoded paths (determined at configure time), and allow override
> using a config file. Have a command line option for saying where the
> config file should be.
>
>
> -Original Message-
> From: Shachar Shemesh [mailto:[EMAIL PROTECTED]
> Sent: 09 May 2004 10:20
> To: Dave Page
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED];
> [EMAIL PROTECTED]
> Subject: Re: [HACKERS] Relocatable installs
>
> I don't think that's
Dave Page wrote:
Anyway, the point is that to do that you need to write to
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\EventLog\
(off the top of my head) otherwise, the messages logged in the event log
are pretty unreadable. Service installation will also require admin
privileges.
Regards
It's rumoured that Marc Slemko once said:
>> > For Windows, replace config file with "Registry". That is usually
>> > hardcoded for (depending on whether you want it changeable per-user)
>> > HKEY_LOCAL_MACHINE\Software\\ (replace
>> > HKLM with HKEY_LOCAL_USER if you want per-user config).
>>
>> D
On Sun, 9 May 2004, Bruce Momjian wrote:
> Shachar Shemesh wrote:
> > Bruce Momjian wrote:
> >
> > >Comments?
> > >
> > >
> > What's wrong with the way it's done by everybody else?
> >
> > Have hardcoded paths (determined at configure time), and allow override
> > using a config file. Have a comma
Bruce Momjian wrote:
Shachar Shemesh wrote:
Bruce Momjian wrote:
Comments?
What's wrong with the way it's done by everybody else?
Have hardcoded paths (determined at configure time), and allow override
using a config file. Have a command line option for saying where the
config file
Bruce Momjian wrote:
Comments?
What's wrong with the way it's done by everybody else?
Have hardcoded paths (determined at configure time), and allow override
using a config file. Have a command line option for saying where the
config file should be.
For Windows, replace config file with "Regi
Shachar Shemesh wrote:
> Bruce Momjian wrote:
>
> >Comments?
> >
> >
> What's wrong with the way it's done by everybody else?
>
> Have hardcoded paths (determined at configure time), and allow override
> using a config file. Have a command line option for saying where the
> config file should
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Ah, got it. Makes sense. We do searches for finding our own path, but
> you can argue that this predictable --- we know we are running so the
> binary must be somewhere. :-) However, the version checking we do now
> is a little non-predictable because
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > Ah, got it. Makes sense. We do searches for finding our own path, but
> > you can argue that this predictable --- we know we are running so the
> > binary must be somewhere. :-) However, the version checking we do now
> > is a litt
Andrew Dunstan <[EMAIL PROTECTED]> writes:
> Tom Lane wrote:
>> I think we should use the relative-path method *unless* the configure
>> command called out specific installation directories (that is, not
>> just --prefix but --datadir and/or related options).
> I think we could adopt a simple rule
Andrew Dunstan wrote:
> >I think we should use the relative-path method *unless* the configure
> >command called out specific installation directories (that is, not
> >just --prefix but --datadir and/or related options). If you use one of
> >those then that absolute path should be used always, ie,
Bruce Momjian <[EMAIL PROTECTED]> writes:
> Marc G. Fournier wrote:
>> Is there a reason why we can't use a PGSQL_PREFIX ENV variable or
>> something like that? If not defined, use compiled in default?
> Win32 isn't going to be able to define that.
And this idea is even worse than the other one
Tom Lane wrote:
> Bruce Momjian <[EMAIL PROTECTED]> writes:
> > My idea is to write a /port function that uses various methods to find
> > the needed files. We could look in the relative location first, and if
> > the needed file is not found, look in the hardcoded directory.
>
> I think a "searc
Tom Lane wrote:
Bruce Momjian <[EMAIL PROTECTED]> writes:
My idea is to write a /port function that uses various methods to find
the needed files. We could look in the relative location first, and if
the needed file is not found, look in the hardcoded directory.
I think a "search until yo
Marc G. Fournier wrote:
> > However, right now, if you try to move /usr/local/pgsql to /var/pgsql,
> > the database will not work because there are hard-coded directory
> > dependencies in the binaries:
> >
> > initdb has to find its *.bki files in /share
> > initdb has to find the postgres
On Sat, 8 May 2004, Bruce Momjian wrote:
> Win32 is going to need relocatable installs, and Unix packagers have
> asked for this too.
>
> A relocatable install is one where you can do 'gmake install', tar up
> the directory where you installed it, then untar it on to another
> machine with the sam
Bruce Momjian <[EMAIL PROTECTED]> writes:
> My idea is to write a /port function that uses various methods to find
> the needed files. We could look in the relative location first, and if
> the needed file is not found, look in the hardcoded directory.
I think a "search until you find something"
Win32 is going to need relocatable installs, and Unix packagers have
asked for this too.
A relocatable install is one where you can do 'gmake install', tar up
the directory where you installed it, then untar it on to another
machine with the same operating system, but into a different directory
lo
44 matches
Mail list logo
