Re: [Vala] Vala on CentOS?



Jan,

Setting the LD_LIBRARY_PATH worked perfectly! I do have two versions
of glib the newest being in /usr/local/lib. So setting that with:
# export PKG_CONFIG_PATH=/usr/local/lib/pkgconfig
# export LD_LIBRARY_PATH=/usr/local/lib
# valac --pkg=gee-1.0 --pkg=json-glib-1.0 main.vala taxonomy.vala

Compiles perfect and runs too! Thank you Jan, Jürg, and Abderrahim so much!

On Fri, Apr 2, 2010 at 11:57 AM, Jan Hudec <bulb ucw cz> wrote:
On Fri, Apr 02, 2010 at 09:44:47 -0700, Joseph Montanez wrote:
[...]
./main: symbol lookup error: ./main: undefined symbol:
g_compute_checksum_for_string

[...]
./main: symbol lookup error: ./main: undefined symbol: g_once_init_enter_impl

Hm, the linker looks up all the symbols at compile (link) time. It didn't,
which suggests it had the symbols and it could only have them from another
version of the shared library in question. That would happen if you had two
versions installed and the compiler and dynamic linker disagreed in the order
of paths.

Also the compiler needed to see declarations of those symbols indicating that
the program was compiled against different (newer -- glib does decent job
with backward compatibility) version than is found at runtime.

I tried "ldd" on the "main" executable and everything keeps linking to
/lib64/ rather then /usr/local/lib:
# ldd main
      libgee.so.2 => /lib64/libgee.so.2 (0x00002aaaaaabe000)
      libjson-glib-1.0.so.0 => /lib64/libjson-glib-1.0.so.0 (0x00002aaaaad06000)
      libgobject-2.0.so.0 => /lib64/libgobject-2.0.so.0 (0x0000003a50c00000)
      libglib-2.0.so.0 => /lib64/libglib-2.0.so.0 (0x0000003a50000000)
      libc.so.6 => /lib64/libc.so.6 (0x0000003a4e000000)
      librt.so.1 => /lib64/librt.so.1 (0x0000003a4f400000)
      /lib64/ld-linux-x86-64.so.2 (0x0000003a4dc00000)
      libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003a4ec00000)

First it might just be, that your ld.so.cache is stale. As root, try running

  ldconfig

If it does not help, I suggest you check the library install directories of
packages you use, whether the undecorated .so files there point to the same
files as listed by ldd or not. You can find the directories in question by
looking at the -L options produced by

  pkg-config --libs all-the-packages-you-use

It's likely they won't. So you have to tell the dynamic linker where to look
for the right files. There are three ways:

 1. Set environment variable LD_LIBRARY_PATH to a list (':'-separated) of
   directories which need to be searched before the default ones.

 2. Record the directories, which need to be searched before the default ones
   in your application at link time. To do that, pass '-rpath /path/to/lib'
   option to the *linker*. That means getting it through gcc by escaping via
   -Wl and through valac by escaping via -X, combining to rather convoluted

     -X -Wl,-rpath,/path/to/lib

   (once for each directory you need to add)

 3. Globally change the settings of ld.so by modifying /etc/ld.so.conf and/or
   adding entries to /etc/ld.so.conf.d. Than you have to run the "ldconfig"
   command as root to update the cache. Beware, that it might, though
   shouldn't if backward compatibility is properly maintained in the
   libraries, break some other program.

I suggest you use 1. to try whether using some extra library directories helps
and which ones they should be and than probably just set the rpath (option
2.) to avoid breaking other stuff.

--
                                                Jan 'Bulb' Hudec <bulb ucw cz>




-- 
Joseph Montanez
Web Developer
Gorilla3D
Design, Develop, Deploy



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]