Re: BUG #1807: cannot build postgresql: libascii_and_mic.so.0.0: No such file or directory

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: "Janet Hempstead" <hempsteadj(at)rogers(dot)com>
Cc: pgsql-bugs(at)postgresql(dot)org
Subject: Re: BUG #1807: cannot build postgresql: libascii_and_mic.so.0.0: No such file or directory
Date: 2005-08-05 05:15:29
Message-ID: 5114.1123218929@sss.pgh.pa.us
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-bugs

"Janet Hempstead" <hempsteadj(at)rogers(dot)com> writes:
> I am trying to build postgresql 8.0.3 on a Sun Ultra 5 running Solaris 9.
> ...
> export LDFLAGS='-L /usr/lib -L /usr/local/lib -L /usr/local/ssl/lib'
> ...
> gcc -shared -h libascii_and_mic.so.0 ascii_and_mic.o
> -L../../../../../../src/port -L -L -L -o libascii_and_mic.so.0.0
> gcc: libascii_and_mic.so.0.0: No such file or directory

Hmm ... I think what happened here is that the first -L ate the second
-L as argument, and then the third -L ate the -o, leaving
libascii_and_mic.so.0.0 looking like an input filename rather than an
output filename to gcc. But this is of course only the symptom --- the
question is how did those argument-less -L switches get into the command
line? I'm guessing that your LDFLAGS switch got munged into this.

The recommended, supported way of specifying library directories is
not through LDFLAGS, but like this:

configure ... --with-libs=/usr/lib:/usr/local/lib:/usr/local/ssl/lib

I think that your LDFLAGS approach might have worked if you'd left out
the spaces between the -L's and the directories, but given the way we
whack LDFLAGS around in the makefiles, it definitely won't work with
spaces :-(

regards, tom lane

In response to

Browse pgsql-bugs by date

  From Date Subject
Next Message Sivaraman K.G 2005-08-05 06:13:56 Cache lookup failed !!!
Previous Message Andrew - Supernews 2005-08-04 23:19:11 Re: Multiple-action rule surprise