-Re: Hardcoded java paths in shared objects [was:Re: Building is too difficult and release of a first pre-built egg]
Roman Chyla 2011-06-02, 21:29
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?
> 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.
>> 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