Re: [Vala] Vala on CentOS?

[Joseph Montanez <jmontanez gorilla3d com>]

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