Обсуждение: Not finding local variables and libs
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.
--
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
-----------------------------------------------------------------
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
-----------------------------------------------------------------