0

Everytime when I want to build application from source on linux, I have to install dependencies libraries in my operating system (ubuntu).

Typical scenario:

Start ./configure Got error about missing library: xyz sudo apt-get install libxyz-dev Go to step 1. At the end I finish with mess in my operating system and problem with dependencies. For instance:

The following packages have unmet dependencies:

 librsvg2-dev : Depends: libglib2.0-dev (>= 2.12.0) but it is not going to be installed
                Depends: libgdk-pixbuf2.0-dev (>= 2.21.6) but it is not going to be installed
                Depends: libcairo2-dev (>= 1.2.0) but it is not going to be installed
                Depends: libgtk2.0-dev (>= 2.21.5) but it is not going to be  installed

Always ask myself what now ? Should I force ubuntu to install higher version of library ?

Here is my question:

Maybe there is another way to building software on linux(ubuntu) from source. Some isolate way. Not integrating to my OS ? I'm coming from java world and there, building a application != install every dependency in system. Any suggestion ? Best practice ?

chris
  • 101
  • As @goldilocks says, you have more than one question here. If you want to check out what is going on with the librsvg2-dev` error above, you could run `apt-cache policy` for all of `librsvg2-dev`, `libglib2.0-dev`, `libgdk-pixbuf2.0-dev`, `libcairo2-dev`, `libgtk2.0-dev` to see what versions you have installed. You could post these results in the question. This is really a separate question from your main question. – Faheem Mitha Nov 29 '13 at 12:08

2 Answers2

3

You have more than one question here, and I think the main one is how to deal with "but it is not going to be installed". I don't have a answer to that, but I can say if this happens because you've gotten frustrated and forced an install of something at some point, then you have to learn to slow down and pay attention to specifics. Simply saying, "at the end I finish with mess" doesn't say much.

I've been building from source on linux for more than a decade and in terms of the distro package manager rarely had any issues. Some source packagers do not do a very good job of indicating dependencies, or getting .configure to do it properly, and this can be a big hassle, but it shouldn't lead to "unmet dependency" problems with your distro binary stuff, unless you've done something wrong with the distro installer.

For example:

librsvg2-dev : Depends: libglib2.0-dev (>= 2.12.0)

2.12 is ancient -- I couldn't find a version history online, but I think ~10 years ancient. There's no way you have a version of ubuntu which uses a glib older than this. So something has gone way wrong with your package management.

That has nothing much to do with the procedure for source builds.

I'm coming from java world and...

So, this is the C/C++ world. Java is more monolithic and self-contained, which makes certain things easier, but there are tradeoffs -- keep in mind C/C++ has some advantages of it's own.

goldilocks
  • 86,451
  • 30
  • 200
  • 258
0

Java is delivered with most libraries already in the virtual machine, sometimes Java programs contain external libraries packed in the jar. However if you have a lot of programs that are bundled with the same libraries you are wasting a lot of space.
Java itself pulls in a lot of dependencies and provides your software with everything they need. I often think of Java as a wrapper for different operating systems libraries, unifying their functionality. Although this isn't completely true and Java offers a lot more.

There is a great package manager that compiles every software from source, takes care of dependencies, installs them when needed and removes them after they are no longer needed. However Portage it is the core of Gentoo Linux, it is possible to use it alongside other package managers, but I have no experience how well this actually works.
You can check out Gentoo-Prefix to introduce Portage to any OS other than Gentoo itself, but I have to warn you that this probably isn't very easy to do, most certainly highly experimental and likely to break everything.

Baarn
  • 882
  • 2
  • 11
  • 18