Anjuta recompile issues

English Programming/Scripting
1

I’m a semi-newbie, with an AMD64 box running 10.3 x64, generally successful. I have mostly stuck to the various package versions that came with the distribution or the update server, with regards to gcc, etc.

On my box, when I try running Anjuta as it comes from the distribution, I get three missing-library errors on load-up, pertaining to plugins, as I recall.

So I decided to just get Anjuta 2.4 sources and build them out; I run the configure script, resolve dependencies, re-run, etc, until everything is “OK”. (Except I can’t figure out how to get it to compile with GtkSourceView editor, yet, but that’s another story.)

So, with it configured for everything but GtkSourceView and some marked-unstable other plug-in, I started the make.

It successfully makes all the way up to the valgrind plug-in, which fails to link the library giving “relocation R_X86_64_32 against `a local symbol’ can not be used when making a shared object; recompile with -fPIC .libs/assert.o: could not read symbols: Bad value”

Digging around, I saw this page:
Gentoo Linux Documentation – HOWTO fix -fPIC errors

So i thought I’d pull down the latest source of binutils and build/install it, and this is where I run into trouble.

I was able to compile and build it using “–with-pic”, and “sudo make install”. It appears to put the new libbfd* libraries in /usr/local/bin, whereas the old distribution-level library file remains in /usr/lib64. And this is what the Anjuta build picks up, still.

I started to try to uninstall the distribution binutils using yast, but realized there were dozens of dependencies on binutils that would come unglued, so I figured this wasn’t a good idea.

My questions are:

  • What’s the right way to do this?
  • Should I specify a different target folder for the binutils install (ie, /usr/lib64?)
  • Since I presume many other packages depend on the old 2.17 version of binutils, is it acceptable to have two versions of libbfd*.so in /usr/lib64?
  • Given the above, does the automake/autoconf mechanism seek out the latest version of a library to link up with, in the case of Anjuta?
  • Is it possible/reasonable to use the binutils package to build an update(?) RPM that would update 2.17 binutils to the 2.18 version for the whole system?
  • Other advice?
2

I figured it out, or at least, I figured something out. I ended up copying just the libbfd files generated by the 2.18 binutils build into /usr/lib64, replacing the .a (static) lib and supplementing the shared lib.

This way, the existing compiler tools still run against the 2.17 version from the SUSE repositories, and anjuta could build against the 2.18 version built from source.

Seemed to work fine, although Anjuta (2.4) threw a number of odd asserts to the console as it worked; obviously needs some TLC.

3

Why don’t you just tell it to look for the libraries in /usr/lib64 instead? This is accomplished by passing --prefix=/usr --libdir=/usr/lib64 to configure

4

Probably because I didn’t know how to do this; I’m still pretty new to the automake/autoconf paradigm.

I also suspect I could or should have used /usr/lib64 as the target for binutils build. What controls whether automake/autoconf uses ./lib vs ./lib64 on a given distribution? Or is that tied directly to the source packages’ choices?

More to learn, more to learn… :slight_smile:

5

That would be the system utils, suse is configure (bash, compilers, etc), to use /lib64 and /lib, however, /lib is only supposed to contain 32-bit packages.

As to setting PKG_CONFIG paths, use
PKG_CONFIG_PATH=/usr/lib64/pkgconfig [command to build]