Re: Mac OS X make check errors... - Mailing list pgsql-bugs

I only added the --disable-shared from a
recommendation on the  cocoa developers forum. Someone
reported problems using libpq.a and the solution
offered was the above.

The original person spoke of problems linking libpg.a.
The poster mentioned something about even though he
specified the libpg.a, the linker was finding the
dynamic library. I can neither confirm nor deny  this
finding.

Here is the original post....

I have a cocoa application that I link against a
postgresql library.

There appear to be two  libraries to choose from
  libpq.a and libpg3.2.dylib

I picked libpq.a in Xcode but otool shows that
the compiled program will use libpg3.2.dylib

Is there a way I can have the linker do a static
link for this one library? ( ie use libpq.a )

(I am currently using ver 8.0.0b3 for postgresql
  but most of the world is using version 7.x.x)

___________ and the answer from the same person......


It appears that the linker will choose a dylib
over an archive lib.

I got around the problem by moving the dylibs out
of the directory containing libpq.a and then
was able to get the libpq to be staticly linked
into the image.

The only one I could get libpq.a into the build
process was to drag the file onto the project.
Then open panel in the add file to project would
not let me choose the static library.

I guess I will need to keep a copy of the static
lib in some other directory...

___________ and the answer from another source...


If you do:

   ./configure --disable-shared

You can build without getting the dylib.

    - Scott


--- Tom Lane <tgl@sss.pgh.pa.us> wrote:

> Theodore Petrosky <tedpet5@yahoo.com> writes:
> > I just tried the newest beta (3) and for the first
> > time I am getting multiple errors in 'make check'.
>
> > this is my configure line...
> > ./configure --with-rendezvous
> --enable-thread-safety
> > --disable-shared
> > ...
> >  7 of 96 tests failed, 1 of these failures
> ignored.
>
> --disable-shared means you do not get any of the
> backend extensions that
> come as shared libraries; this includes plpgsql (and
> the other PL
> languages if you had tried to build 'em) as well as
> character set
> conversions.  I think the tests that failed are
> exactly the ones that
> depend on plpgsql or conversions.
>
> I notice that pg_regress.sh has a kluge to cause it
> to ignore the
> failure of the plpgsql regression test when
> --disable-shared is true,
> but this seems a totally lost cause with so many
> other tests now making
> use of that language.  I propose taking out that
> special case.
>
> Peter, I think you were the one who put in the
> special case to begin
> with; do you have any better ideas?
>
>             regards, tom lane
>



_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com