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 <[email protected]> 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 <[email protected]> > -- Joseph Montanez Web Developer Gorilla3D Design, Develop, Deploy _______________________________________________ Vala-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/vala-list
