Обсуждение: 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 -----------------------------------------------------------------