Re: [Linphone-users] how to install belle-sip-1.3.0 package on the ubuntu 14.04 64bit?

[J G Miller]

At 02:06h, on Sunday, June 22, 2014,
in message <address@hidden>,
on the subject of "Re: [Linphone-users] how to install belle-sip-1.3.0 package 
on the ubuntu 14.04 64bit?", 
Kl Trm wrote -

 > Thank you for your answer.

You are welcome.

 > Is it the right one?

Well what does this line say

 > Provides: libglew1.5-dev, libglew1.6-dev

because that answers your question.

 > In the synaptic package manager I searched
 > 
 > libgl1-mesa-dev libgl-dev libglew1.10 (= 1.10.0-3) libglu1-mesa-dev 
 > libglu-dev
 > 
 > libgl-dev and libglu-dev package is not present. That does not matter?

It only matters if you need libgl-dev and libglu-dev to compile source code 
which 
needs headers etc for the gl and glu libraries.

 > I was told not to install a package in the synaptic package manager in order 
 > to apply to requirements for an eksternal program

Who told you that?  It is sensible advice in general, but not advice 
appropriate for every situation,
particularly with respect to dev packages.

And when it comes to compiling source code for an "external" program, you have 
to
install the development package(s).

> if another package then has to be uninstalled, because that will affect other 
> software on the computer.

Yes and it can affect other software in bad ways and good ways, the important 
thing is to
first find out what it affects,

               apt-cache  rdepends   libupnp4-dev

Now the important thing to note here is that you are looking at "dev" packages. 
 libupnp4-dev
was installed by you because dev packages do not come installed by default.  It 
is only other
dev packages which may depend on libupnp4-dev not any installed program whose 
dependencies are
on the library package (eg libupnp4) and not the dev package (eg libupnp4-dev)

So you could purge libupn4-dev from your system and it would not make any 
difference to any of
the package installed programs.

Furthermore, on a recently installed Linux Mint 17 (derived from Ubuntu 14.04) 
I only see libupnp6
installed installed

 dpkg -l | grep libupnp
ii  libupnp6             1:1.6.17-1.2           amd64                  Portable 
SDK for UPnP Devices, version 1.6 (shared libraries)
ii  libupnp6-dev         1:1.6.17-1.2           amd64                  Portable 
SDK for UPnP Devices, version 1.6 (development files)
ii  libupnp6-doc         1:1.6.17-1.2           all                    
Documentation for the Portable SDK for UPnP Devices, version 1.6

So you should really be checking to find out why you still have libupnp4 
installed with

                        apt-cache  rdepends   libupnp4

Either you have some program installed which is still using libupnp4 or 
possibly you did
an upgrade rather than a clean install of Ubuntu 14.04, because the above 
command on that
system shews no program needing libupn4.

 > What do you suggest? The packages 'libupnp4'   and 'libupnp6' are installed. 

Live dangerously and try

             dpkg --simulate  purge   libupnp4 libupnp4-dev

and look at the error messages if any.

I suspect that you installed libupnp4-dev in error, which caused libupnp4 to be 
installed
and that is the only reason it is present on your new shiny 14.04. 

 > Does the solution mean, that you get a package not from the synaptic package 
 > manager

No you do not get a [deb] package per se, you get the source code and compile 
it and tell it to
install in /usr/local (as you do with the needed version of the belle-sip 
library)

 > install it and point at it in a way, that the package will only be used by 
 > the program

When running configure extracted from source code tar archives, provided that 
it is relatively
recent and not a configure put together from years ago, the commands in that 
file which are used
for locating the presence of header files and library files PKG_CONFIG_PATH 
look for library_name.pc
files in the directories given in that order.  So if /usr/local/lib is before 
/usr/lib and the appropriate
.pc file is found in /usr/local/lib it will use whatever that points to rather 
than the distribution
version in /usr/lib.

This is also one of the reasons why it is best practice to always install 
"external" software under
/usr/local and not /usr, in order to prevent such distribution files from being 
overwritten.

> It will not affect the rest of the software?

It all depends.  If the software is created with a specific library version and 
that library version
is built into the compiled version of the executable then there is nothing to 
worry about.  If that is
not the case then one has to worry about LD_LIBRARY_PATH environmental variable 
containing the
library paths in the appropriate order.

 > How I do it, I do not get. I do not know what to write.

I provided you an example of what to write.  You need to understand shell 
environmental variables.

When you fire up an X terminal emulator and get a shell (restricting the 
discussion here to /bin/bash)
then you can at the command line do

     export PKG_CONFIG_PATH="a list of paths to .pc files"

eg

 PKG_CONFIG_PATH="\
/usr/local/lib/pkgconfig:\
/usr/local/X11R6/lib/pkgconfig:\
/usr/lib/${arch_library}/pkgconfig:\
/usr/lib/pkgconfig:\
/usr/share/pkgconfig\
"

Now that environmental variable exists only for as long as the shell process 
continues to run.

So having set that variable you can then do ./configure in the appropriate 
directory and all
should be well.

Now if you want to avoid having to type all that in every time, you can store 
the text in
a file and then source it

                 . name_of_script_file_containing_environmental_variables

when needed or include it in a shell script which also executes the configure 
etc.

In my case I include it in a shell script which actually unpacks, runs 
configure, makes,
installs, and then stows the "external" program, because when one is building 
from source
and on multiple machines, being able to just type

                build belle-sip
                build linphone

is a lot more efficient (build being my shell script and not some system 
command).

The thing to realize with GNU/Linux systems is that if one wants to do 
something which
is not provided by somebody else, then one may first have to make some needed 
bricks
along with getting the bricks that are already available, and then putting the 
bricks
together to make the structure.

Hope that helps ...   ;+)