[sip-comm-dev] instalations and native libs


#1

Hi,

There was a problem with the installations I've just fixed them(we haven't added the bundles and libs for the sip,msn and callhistory).
But as the jmf libs are in the bundle what about the natvie libs. where to place them so they can be added to the path or library path ?

damencho

···

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#2

Hi Damencho,

Hi,

There was a problem with the installations I've just fixed them(we
haven't added the bundles and libs for the sip,msn and callhistory).

Great! Does this mean that we now have a working windows installation?

But as the jmf libs are in the bundle what about the natvie libs. where

Good question. However, I think the problem does not only concern JMF and
that we need a more generic rule for natives. We're going to need native
libs for jdics as well and I am sure that other cases would also appear. So
here's what I suggest. Inside lib we have a "native" directory. Inside this
directory we can create os-specific subdirs that contain shared libs for the
corresponding OS (e.g. native/macosx native/windows native/linux and etc.).
We put all native libs directly inside these subdirectories.

The scripts that generate the installers would then get the libs (.so or
.dll) that they need and make sure that when the installed sip-communicator
is executed, its LD_LIBRARY_PATH or PATH env vars contain all the dlls that
were in the corresponding native/xxx dir.

How does this sound? I feel that I might have been unclear so let me know if
I need to explain further.

Damencho would this be ok for the IzPack packages? Martin, Pavel, Romain,
would that be ok for your packages?

Emil

to place them so they can be added to the path or library path ?

···

On 11/14/06, Damian Minkov <damencho@damencho.com> wrote:

damencho

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

Yes this is ok and ok for IzPack . The installation will be working after I commit my changes :))

Emil Ivov wrote:

···

Hi Damencho,

On 11/14/06, *Damian Minkov* <damencho@damencho.com > <mailto:damencho@damencho.com>> wrote:

    Hi,

    There was a problem with the installations I've just fixed them(we
    haven't added the bundles and libs for the sip,msn and callhistory).

Great! Does this mean that we now have a working windows installation?

    But as the jmf libs are in the bundle what about the natvie libs.
    where

Good question. However, I think the problem does not only concern JMF and that we need a more generic rule for natives. We're going to need native libs for jdics as well and I am sure that other cases would also appear. So here's what I suggest. Inside lib we have a "native" directory. Inside this directory we can create os-specific subdirs that contain shared libs for the corresponding OS ( e.g. native/macosx native/windows native/linux and etc.). We put all native libs directly inside these subdirectories.

The scripts that generate the installers would then get the libs (.so or .dll) that they need and make sure that when the installed sip-communicator is executed, its LD_LIBRARY_PATH or PATH env vars contain all the dlls that were in the corresponding native/xxx dir.

How does this sound? I feel that I might have been unclear so let me know if I need to explain further.

Damencho would this be ok for the IzPack packages? Martin, Pavel, Romain, would that be ok for your packages?

Emil

    to place them so they can be added to the path or library path ?

    damencho

    ---------------------------------------------------------------------
    To unsubscribe, e-mail:
    dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    For additional commands, e-mail:
    dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Now that I think of it, there is another solution that we need to take into
account when generating installation packages (dmg, deb, rpm, exe, bin).
The Oscar OSGi implementation supports native libs integrated inside
specific bundles so it is possible for a bundle to include all native libs
it needs. The installation script would however have to choose among
alternate win, lin and macosx bundles and not include bundles that contain
natives not matchinng the destination OS.

There is however a problem I fear in this scenario. I don't know how exactly
oscar handles native libs but I imagine it is through a java specific way -
like mofifying the java.library.path sys property. This causes problems when
one shared library depends on another (A.so depends on B.so). The first one
(A.so) is properly loaded because java knows where it is and can access it
directly, but A.so cannot access the second one (B.so) since it, as a native
application, ignores java properties. In the end we get a
LinkNotSatisfiedError.

I've had a similar problem with JMF and Webstart. JMF for linux has a shared
lib called libjmutil.so and it is referenced by other JMF .so's. When
downloaded through webstart this configuration fails beause libjmutil.so is
nowhere to be seen in LD_LIBRARY_PATH.

In the end, what I mean is that we'd better have both options for
distributing natives, which gives us something like this:

1. Anything in a lib/native/os directory is understood by the installation
packet generators as native shared libs and is added to the PATH (for
windows) and and LD_LIBRARY_PATH for linux (and macosx?).

2. We agree, on a location where we store platform specific native bundles,
like for example, sc-bundles/native/os, and installation packet generators
use this location to add platform specific bundles.

Does this make sense?
Emil

···

On 11/14/06, Damian Minkov <damencho@damencho.com> wrote:

Yes this is ok and ok for IzPack . The installation will be working
after I commit my changes :))

Emil Ivov wrote:
> Hi Damencho,
>
> On 11/14/06, *Damian Minkov* <damencho@damencho.com > > <mailto:damencho@damencho.com>> wrote:
>
> Hi,
>
> There was a problem with the installations I've just fixed them(we
> haven't added the bundles and libs for the sip,msn and callhistory).
>
> Great! Does this mean that we now have a working windows installation?
>
> But as the jmf libs are in the bundle what about the natvie libs.
> where
>
> Good question. However, I think the problem does not only concern JMF
> and that we need a more generic rule for natives. We're going to need
> native libs for jdics as well and I am sure that other cases would
> also appear. So here's what I suggest. Inside lib we have a "native"
> directory. Inside this directory we can create os-specific subdirs
> that contain shared libs for the corresponding OS ( e.g. native/macosx
> native/windows native/linux and etc.). We put all native libs directly
> inside these subdirectories.
>
> The scripts that generate the installers would then get the libs (.so
> or .dll) that they need and make sure that when the installed
> sip-communicator is executed, its LD_LIBRARY_PATH or PATH env vars
> contain all the dlls that were in the corresponding native/xxx dir.
>
> How does this sound? I feel that I might have been unclear so let me
> know if I need to explain further.
>
> Damencho would this be ok for the IzPack packages? Martin, Pavel,
> Romain, would that be ok for your packages?
>
> Emil
>
> to place them so they can be added to the path or library path ?
>
> damencho
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> dev-unsubscribe@sip-communicator.dev.java.net
> <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
> For additional commands, e-mail:
> dev-help@sip-communicator.dev.java.net
> <mailto:dev-help@sip-communicator.dev.java.net>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hi,

Just to give you one idea.
It is possible to use JNLP (Java Web Start) with Native Libs and if you prefer to have installation (SetUp) program you can use the tool jnlp2msi or jnlp2linux or jnlp2solaris from JDIC.

Regards,
Miro.

Damian Minkov wrote:

···

Yes this is ok and ok for IzPack . The installation will be working after I commit my changes :))

Emil Ivov wrote:

Hi Damencho,

On 11/14/06, *Damian Minkov* <damencho@damencho.com >> <mailto:damencho@damencho.com>> wrote:

    Hi,

    There was a problem with the installations I've just fixed them(we
    haven't added the bundles and libs for the sip,msn and callhistory).

Great! Does this mean that we now have a working windows installation?
    But as the jmf libs are in the bundle what about the natvie libs.
    where

Good question. However, I think the problem does not only concern JMF and that we need a more generic rule for natives. We're going to need native libs for jdics as well and I am sure that other cases would also appear. So here's what I suggest. Inside lib we have a "native" directory. Inside this directory we can create os-specific subdirs that contain shared libs for the corresponding OS ( e.g. native/macosx native/windows native/linux and etc.). We put all native libs directly inside these subdirectories.

The scripts that generate the installers would then get the libs (.so or .dll) that they need and make sure that when the installed sip-communicator is executed, its LD_LIBRARY_PATH or PATH env vars contain all the dlls that were in the corresponding native/xxx dir.

How does this sound? I feel that I might have been unclear so let me know if I need to explain further.

Damencho would this be ok for the IzPack packages? Martin, Pavel, Romain, would that be ok for your packages?

Emil

    to place them so they can be added to the path or library path ?

    damencho

    ---------------------------------------------------------------------
    To unsubscribe, e-mail:
    dev-unsubscribe@sip-communicator.dev.java.net
    <mailto:dev-unsubscribe@sip-communicator.dev.java.net>
    For additional commands, e-mail:
    dev-help@sip-communicator.dev.java.net
    <mailto:dev-help@sip-communicator.dev.java.net>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net