Not finding local variables and libs

On Mon, 10 Feb 2003, Martin Marques wrote:

Last week I upgraded PostgreSQL to 7.3.1 and PHP to 4.3 last week, and I found
that the CLI is giving me lots of headaches.
At first, a script that had to recieve mail form a pipe (an alias) and insert
data into my PostgreSQL database stopped working. Put PEAR::DB on the script
and found that the connection didn't find that database (not the server, the
database where it should be inserted the data). If I execute the script from
the command line "cat some-mail | /usr/local/bin/php/arch.php" it works
great, but not if it's passed by the mail system.
Today I found out that the administration crons that run on sunday also didn't
work, even though the same command works from the postgres bash. The postgres
crontab looks like this:

0 23 * * 0 /usr/local/pgsql/bin/vacuumdb -z -v lismarch
10 23 * * 0 /usr/local/pgsql/bin/vacuumdb -z -v horde
30 23 * * 0 /usr/local/pgsql/bin/vacuumdb -z -v webunl

I got error reports from mail that said this:

Your "cron" job on bugs
/usr/local/pgsql/bin/vacuumdb -z -v lismarch

produced the following output:

ld.so.1: /usr/local/pgsql/bin/psql: fatal: libgcc_s.so.1: open failed: No such
file or directory
Killed
vacuumdb: vacuum lismarch failed

I thought it was a PHP problem, but these commands are especifically from
PostgreSQL, so I guess the problem is there.

Are the environments different, maybe something like LD_LIBRARY_PATH or
some such?

On Mon, 10 Feb 2003, Stephan Szabo wrote:

ld.so.1: /usr/local/pgsql/bin/psql: fatal: libgcc_s.so.1: open failed: No such
file or directory
Killed
vacuumdb: vacuum lismarch failed

I thought it was a PHP problem, but these commands are especifically from
PostgreSQL, so I guess the problem is there.

Are the environments different, maybe something like LD_LIBRARY_PATH or
some such?

you may be able to determine the location of libgcc_s.so.1 with

gcc -print-libgcc-file-name

once you find the library you need to make sure ld.so can find it at runtme.
LD_LIBRARY_PATH _can_ do this but it's a hack. better to tell the binaries
(like psql) that need this library where to find it themselves using, for
example,

* edit /etc/ld.so.conf and run ldconfig
* use the -rpath argument of the linker to set to the location of
libgcc_s.so
* recompile with LD_RUN_PATH set to the location of libgcc_s.so

man ldd

man ld.so

will explain these.

-a

--

====================================
| Ara Howard
| NOAA Forecast Systems Laboratory
| Information and Technology Services
| Data Systems Group
| R/FST 325 Broadway
| Boulder, CO 80305-3328
| Email: ahoward@fsl.noaa.gov
| Phone: 303-497-7238
| Fax: 303-497-7259
====================================

On Lun 10 Feb 2003 13:03, Stephan Szabo wrote:

ld.so.1: /usr/local/pgsql/bin/psql: fatal: libgcc_s.so.1: open failed: No
such file or directory
Killed
vacuumdb: vacuum lismarch failed

I thought it was a PHP problem, but these commands are especifically from
PostgreSQL, so I guess the problem is there.

Are the environments different, maybe something like LD_LIBRARY_PATH or
some such?

Fixed!
Just linked th libgcc_s.so.1 to /usr/lib.
This never happend with other versions off PostgreSQL, and I have been
building since 7.0.3. It's the first time this happens.

Thanks all!

--
Porqué usar una base de datos relacional cualquiera,
si podés usar PostgreSQL?
-----------------------------------------------------------------
Martín Marqués | mmarques@unl.edu.ar
Programador, Administrador, DBA | Centro de Telematica
Universidad Nacional
del Litoral
-----------------------------------------------------------------