John R Pierce wrote:
I have compiled some C (pljava.c) for solaris sparc 64 bit, setup the
LD_LIBRARY_PATH so postgres can find it, and try and load it.
me=# CREATE FUNCTION sqlj.java_call_handler() RETURNS
language_handler AS 'pljava'LANGUAGE C;
ERROR: could not load library "/opt/myst
John R Pierce writes:
> Bruce Momjian wrote:
>> Ah, good idea. Is pg_config.h the only file that varies from 32 to
>> 64-bit?
> it *appears* to be here, but I don't have the 64 bit file set to compare
> with. there are definately a couple other files that get generated by
> ./configure, inclu
Bruce Momjian wrote:
Tom Lane wrote:
John R Pierce writes:
I don't know if the build trees can be structured so the include
directories can be differentiated the same as the bin and lib...
The RPM distributions are able to deal with this without actually
differentiating: if you
Tom Lane wrote:
> John R Pierce writes:
> > I don't know if the build trees can be structured so the include
> > directories can be differentiated the same as the bin and lib...
>
> The RPM distributions are able to deal with this without actually
> differentiating: if you install both 32- and 6
John R Pierce wrote:
> there's a definite structural problem in that the 32 bit and 64 bit
> Solaris binaries are in the same tree, with just the bin and lib
> directories differentiated. you can in theory install them both, and
> point them to different $PGDATA directories, and have them both
John R Pierce writes:
> I don't know if the build trees can be structured so the include
> directories can be differentiated the same as the bin and lib...
The RPM distributions are able to deal with this without actually
differentiating: if you install both 32- and 64-bit RPMs then the
overlapp
Bruce Momjian wrote:
Yes, great. One point is that while you are trying to fix this for
the one-off case, we should be realizing that we need a proper fix so
all your future upgrades will be clean, and other users will not also
have this problem. I agree with your approach to first find out if
John R Pierce wrote:
> Tom Lane wrote:
> > No, but trying to build against a non-self-consistent set of files is
> > bad. You really need a pg_config.h that matches the original build of
> > the server, and you haven't got that. I think Greg's point is that
> > trying to reverse-engineer that fil
Tom Lane wrote:
No, but trying to build against a non-self-consistent set of files is
bad. You really need a pg_config.h that matches the original build of
the server, and you haven't got that. I think Greg's point is that
trying to reverse-engineer that file is considerably more risky than
bui
John R Pierce writes:
> can someone confirm, the critical files that get customized by
> ./configure are
> $INCLUDEDIR/pg_config.h
> $INCLUDEDIR/server/pg_config.h (apparently identical)
> $LIBDIR/pgxs/src/Makefile.global
I believe all of the files that get written at the end of c
Greg Smith wrote:
I'm not trying to criticize what you're doing, just given you a dose
of my own paranoia and preferred risk management approach for this
sort of thing. It may not actually be possible to fully follow the
unreasonable requirements you've been given and deliver something that
w
John R Pierce wrote:
so you're saying that building plugins to work with an existing system
is bad? then whats the point of the whole pgxs system and including
server headers in a binary release?
It's fine if your package has been setup to allow it. I bundle up stuff
on RHEL like that all
Tom Lane wrote:
Right. If you can get a consistent fileset from Bjorn in a timely
fashion, problem solved.
exactly. that is my intent. Bjorn replied to my request on hackers
last night, and 'is going to look into it'
can someone confirm, the critical files that get customized by
./c
John R Pierce writes:
> Greg Smith wrote:
>> If I were John, I'd be preparing to dig in on providing a complete
>> source build with PL/Java installed. It looks like the idea that
>> they'll be able to take their *existing* Solaris binaries and just add
>> Java on top of them is going to end u
Greg Smith wrote:
If I were John, I'd be preparing to dig in on providing a complete
source build with PL/Java installed. It looks like the idea that
they'll be able to take their *existing* Solaris binaries and just add
Java on top of them is going to end up more risky than doing that.
The
Tom Lane wrote:
John R Pierce writes:
I need to build pl/java to run against the binary release of Postgres
for largely political/corporate reasons. this is to be installable as
an addon to an existing large/complex database deployment.
Well, in that case you'd better pester whoever
John R Pierce writes:
> Using the include files provided with the 64bit version is giving me the
> wrong Float8 type, yes, as they are the 32bit include files.
> I need to build pl/java to run against the binary release of Postgres
> for largely political/corporate reasons. this is to be insta
Tom Lane wrote:
John R Pierce writes:
I have compiled some C (pljava.c) for solaris sparc 64 bit, setup the
LD_LIBRARY_PATH so postgres can find it, and try and load it.
me=# CREATE FUNCTION sqlj.java_call_handler() RETURNS language_handler
AS 'pljava'LANGUAGE C;
ERROR: cou
John R Pierce writes:
> I have compiled some C (pljava.c) for solaris sparc 64 bit, setup the
> LD_LIBRARY_PATH so postgres can find it, and try and load it.
> me=# CREATE FUNCTION sqlj.java_call_handler() RETURNS language_handler
> AS 'pljava'LANGUAGE C;
> ERROR: could not load library
I have compiled some C (pljava.c) for solaris sparc 64 bit, setup the
LD_LIBRARY_PATH so postgres can find it, and try and load it.
me=# CREATE FUNCTION sqlj.java_call_handler() RETURNS language_handler
AS 'pljava'LANGUAGE C;
ERROR: could not load library "/opt/mystuff/pljava/pljava.so":
20 matches
Mail list logo
