On Thu, Jun 2, 2011 at 12:26 PM, Andi Vajda <[email protected]> wrote:
>
> On Jun 2, 2011, at 3:10, Philippe Ombredanne <[email protected]> wrote:
>
>> On 2011-06-01 20:54, Roman Chyla wrote:
>>> Note that the
>>> location of the java that was used for the project built will be
>>> hardcoded inside the dynamic library, but I plan to change the header
>>> and set a few standard paths there.
>> This is actually worse than I thought: not only the java location seems 
>> hardcoded in the shared object as a hard path to the libs folder, but also 
>> there is an implied dep on setuptools via pkg_resources
>> So for now, you cannot even build on a jdk and deploy on a jre.
>
> If the solution to this is to remove the hardcoded paths and expect the 
> dynamic linker to find the dependencies via some environment variable like 
> LD_LIBRARY_PATH you'd be creating a security vulnerability.

I am not an expert on this, but i remember that LD_LIBRARY_PATH was
not recommended (as it could break other libraries, if i remember
well). So that's why I thought more about a 'more, standard' hardcoded
locations. Or is there something else besides LD_LIBRARY_PATH and
multiple hardcoded paths?

Roman

> This is how I did it originally (years ago) and people complained about it so 
> I switched to hardcoded paths for shared library dependencies wherever 
> possible.
>
> Andi..
>
>>
>> --
>> Cordially
>> Philippe
>>
>> philippe ombredanne | 1 650 799 0949 | pombredanne at nexb.com
>> nexB - Open by Design (tm) - http://www.nexb.com
>> http://eclipse.org/atf - http://eclipse.org/soc - http://eclipse.org/vep
>> http://drools.org/ - http://easyeclipse.org - http://phpeclipse.com
>

Reply via email to