From: | Randall Perry <rgp(at)systame(dot)com> |
---|---|
To: | <pgsql-general(at)postgresql(dot)org> |
Subject: | Re: Serious environment problem with 7.2 on Solaris |
Date: | 2002-05-24 13:55:56 |
Message-ID: | B913BEAC.1555E%rgp@systame.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Been getting help for this problem on the gcc list, and finally got a
solution that works for me. Hope it helps you too.
The last configure command I tried before I got the solution was:
setenv LDFLAGS="-L/usr/local/lib -Wl,-R/usr/local/lib"; ./configure
--with-libraries=/usr/local/lib:/usr/local/ssl/lib:/usr/local/lib/sasl
--enable-syslog
Below is a private email from Peter Kurpis of gcc list, which solved the
problem. It involves editing the makefile directly after configure.
-------------------------------------------------------------------------
Yikes. I downloaded the postgres distribution, and tried configuring it
on a couple of systems with different environments. I wasn't able to
set things up properly with flags, and I'm not convinced the build system
is healthy, after the unusual problems I had. :-( (For one thing,
--without-gnu-ld and --with-gnu-ld=no didn't have the right effect:
the build was still using -rpath instead of -R .)
But here's what I suggest:
Run configure --enable-syslog
Afterward, in src/Makefile.port, which is the solaris-specific stuff,
replace:
ifeq ($(with_gnu_ld), yes)
export_dynamic = -Wl,-E
rpath = -Wl,-rpath,$(libdir)
else
rpath = -R$(libdir)
endif
shlib_symbolic = -Wl,-Bsymbolic
with:
rpath = -L/usr/local/pgsql/lib -L/usr/local/lib -L/usr/local/ssl/lib
-L/usr/local/lib/sasl -Wl-R/usr/local/pgsql/lib -Wl,-R/usr/local/lib
-Wl,-R/usr/local/ssl/lib -Wl-R/usr/local/lib/sasl
shlib_symbolic = -Wl,-Bsymbolic
In other words, hardwire what you want to accomplish, as a kludge. It's
ugly, but I think it ought to work. Note that /usr/local/pgsql/lib seems to
be a default install directory -- see libdir in src/Makefile.global .
Since you are not using --libdir (or other similar ones) I think this
ought to stay like this; this is the default situation.
You can check things by running
gmake -np | grep ^LINK
The -n disables making any changes to the file system, -p causes printing
of the internal definitions tables. This will tell you what the build
looks like -- probably a standard build. Then do
gmake -np | grep ^LDFLAGS
and this ought to show you what you want to see.
Let me know how it goes... If you still have problems, cut and past
a line from the actual build, or perhaps you can send a log:
gmake >& make.log
so I can take a look at how (i.e. with which options) builds went.
From | Date | Subject | |
---|---|---|---|
Next Message | mathieu.chappuis@msg-software.com | 2002-05-24 14:09:54 | Strange Result with char concatenation in query. |
Previous Message | Nigel J. Andrews | 2002-05-24 13:45:33 | Re: user defined variables |