List Info

Thread: instalations and native libs
instalations and native libs
user name
 2006-11-14 14:48:38 

  


  

    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 < damenchodamencho.com">damenchodamencho.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* < damenchodamencho.com">
damenchodamencho.com
> <mailto: damenchodamencho.com">damenchodamencho.com>> wrote:
>;
> ; &nbsp;  Hi,
>
&gt; &nbsp; &nbsp; There was a problem with the installations I've just fixed them(we

&gt; &nbsp; &nbsp; haven't added the bundles and libs for the sip,msn and callhistory).
>
&gt;
>
>; Great! Does this mean that we now have a working windows installation?
>
&gt; &nbsp; &nbsp; But as the jmf libs are in the bundle what about the natvie libs.

>; &nbsp; &nbsp; 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"
&gt; directory. Inside this directory we can create os-specific subdirs
&gt; that contain shared libs for the corresponding OS ( 
e.g. native/macosx
> native/windows native/linux and etc.). We put all native libs directly
&gt; 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.
&gt;
> Damencho would this be ok for the IzPack packages? Martin, Pavel,
>; Romain, would that be ok for your packages?

>
> Emil
>
>
>&nbsp; &nbsp;  to place them so they can be added to the path or library path ?
>
>; &nbsp; &nbsp; damencho
&gt;
>&nbsp; &nbsp;  ---------------------------------------------------------------------

>&nbsp;   ; To unsubscribe, e-mail:
&gt; &nbsp; &nbsp;  dev-unsubscribesip-communicator.dev.java.net">dev-unsubscribesip-communicator.dev.java.net
&gt; &nbsp; &nbsp; <mailto: dev-unsubscribesip-communicator.dev.java.net">
dev-unsubscribesip-communicator.dev.java.net&gt;
>&nbsp; &nbsp;  For additional commands, e-mail:
&gt; &nbsp; &nbsp;  dev-helpsip-communicator.dev.java.net">dev-helpsip-communicator.dev.java.net
&gt; &nbsp; &nbsp; <mailto:
 dev-helpsip-communicator.dev.java.net">dev-helpsip-communicator.dev.java.net&gt;
>
>;

---------------------------------------------------------------------
To unsubscribe, e-mail: 
 dev-unsubscribesip-communicator.dev.java.net">dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail:  dev-helpsip-communicator.dev.java.net">dev-helpsip-communicator.dev.java.net





  

  
  
   
     
    






 [1]











   
 





about | contact  Other archives ( Real Estate discussion Medical topics )